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ABSTRACT 


This  thesis  presents  extensions  to  an  implementation  of 
a  kernel  in  a  real-time  distributed  operating  system  for  a 
microcomputer  based  multi-processor  system. 

The  operating  system,  MCORTEX,  is  a  2  level, 
hierarchically  structured,  loop  free,  system  that  permits 
logical  distribution  of  the  kernel  in  the  address  space  cf 
each  process.  The  design  is  based  on  segmented  address 
spaces  and  per  process  stacks.  Process  synchronization  is 
achieved  through  sequencers  and  eventcounts.  MCORTEX  is 
resident  in  the  local  memory  of  each  microcomputer  but 
system  data  is  maintained  in  shared  global  memory. 

MCORTEX  has  been  extended  to  include  a  system  monitor 
process  which  allows  stopping  the  system  to  examine  any 
memory,  shared  or  local,  from  any  location.  The  system  can 
then  be  restarted  without  reinitializing  each  microcomputer. 

This  system  particularly  supports  applications  where 
jobs  are  partitioned  into  a  set  of  multiple  interacting 
asynchronous  processes.  The  system  is  currently  implemented 
on  INTEL  86/12A  single-board  computers. 
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I.  INTRODUCTION 


A.  GENERAL  DISCUSSION 

This  thesis  presents  extensions  to  an  implementation  of 
a  kernel  in  a  real-time  distributed  operating  system  for  a 
microcomputer  based  multi-processor  system,  called  MCORTEX. 

As  the  performance  and  capabilities  of  micro-computers 
continues  to  improve,  it  is  becoming  apparent  that  many 
large  real-time  applications  that  are  managed  by  large  fast 
mini-computers  could  be  managed  by  an  integrated  multi¬ 
processor  system  of  less  expensive,  commercially-available 
micro-computers.  What  a  single  general  purpose  micro¬ 
computer  might  lack  in  speed  could  be  compensated  for  by  a 
system  of  computers  if  it  is  managed  by  an  operating  system 
that  allows  process  synchronization  and  parallel  or 
concurrent  processing. 

There  are  multi-microcomputer  systems  already  in  use 
today  in  real-time  applications.  However,  in  order  to 
accommodate  high  data  input  rates  and  the  addition  of  more 
processors  to  the  system,  custom  interconnections  often  have 
to  be  devised  so  that  system  performance  is  not  degraded. 
These  custom  designs  may  increase  the  cost  of  the  system  and 
reduce  flexibility  in  meeting  the  needs  of  a  variety  of 
applications . 
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The  purpose  of  this  thesis  is  to  continue  development  of 
an  operating  system  design  that  is  simple,  small,  and 
flexible.  A  principal  goal  is  to  demonstrate  the  operating 
system  on  commercially  available,  relatively  inexpensive 
general  purpose  micro-computers  requiring  the  minimum  of 
custom-developed  hardware  for  processor  inter-communication 
and  control.  It  is  anticipated  that  the  design  will  be 
general  in  nature  in  order  to  be  applied  towards  various 
real-time  applications  and  implemented  on  different  micro¬ 
computer  systems  with  the  minimum  of  modification.  The 
specific  goals  of  this  thesis  are  discussed  in  the  next 
section  concerning  the  background  of  the  project. 

B.  BACKGROUND 

The  AEGIS  weapons  system  simulation  project  currently 
being  conducted  at  the  Naval  Postgraduate  School  is 
attempting  to  determine  the  feasibility  of  raplacing  much  of 
the  larger  and  relatively  expensive  mainframe  computer,  the 
AN/UYK-7,  with  a  system  of  16  or  32  bit  micro  computers. 
Several  significant  real-time  functions  of  the  AEGIS  Weapons 
System  are  to  be  duplicated  with  associated  data,  inputs, 
timing,  and  supporting  functions  so  that  a  test  example  can 
be  examined  whose  performance  emulates  that  of  the  actual 
system. 

In  particular,  emulation  of  the  SPY-1A  radar,  which  is  a 
sub-system  of  AEGIS,  is  being  examined.  Signal  processing 


for  long  distance  low  altitude  missile  detection  and  target 
acquisition  for  tactical  missiles  requires  processing  large 
amounts  of  collected  data  in  real-time.  It  is  proposed  that 
a  system  of  micro-computers  as  described  above  could  provide 
th.e  processing  power  required  to  perform  concurrent 
asynchronous  computations. 

Design  of  the  operating  system  that  would  manage  such 
micro-computer  system  was  started  by  Wasson  who  defined  the 
detailed  design  of  an  operating  system  tailored  to  real-time 
image  processing[Ref .  10].  He  based  his  design  on  a  more 
general  model  developed  by  O'Connel  and  Richardson  of  the 
Naval  Postgraduate  School  in  1979.  The  design  was  to  be 
applied  to  the  general  purpose  INTEL  iSBC  86/12A  micro¬ 
computer.  This  single  board  micro-computer  is  based  on  the 
16  bit  INTEL  8086  microprocessor.  Wasson's  design  used  the 
MULTICS  concepts  of  segmentation  and  per  process  stacks  and 
Reed  and  FCanodia's  enventcoui:t  synchronization  methods .  [Ref . 
9:  pp. 12-13]  Rapantzikos  began  the  implementation  of 
Wasson's  design[Ref.  11]. 

The  operating  system,  MCORTEX,  at  this  point  used  the 
concept  of  a  "two  level  traffic  controller''  to  accomplish 
processor  multiplexing  among  a  greater  number  of  eligible 
processes.  This  dual-level  "processor  multiplexing  design" 


allowed  the 

system 

to 

treat  the 

two 

primary  scheduling 

decisions , 

viz . , 

the 

scheduling 

of 

processes  and  the 
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management  of  processors,  at  two  separate  levels  of 
abstraction . 

Cox  continued  the  implementation  effort  of  Rapantzikos 
by  greatly  simplifying  the  design  of  MCORTEX.  He  placed  a 
higher  priority  on  shortening  the  execution  time  in  MCORTEX 
over  the  possible  added  security  of  a  two  level  traffic 
controller  and  therefore,  reduced  the  traffic  controller  to 
one  level  of  abstraction  which  simplified  the 
implementation.  His  other  contribution  was  to  add  a 
gatekeeper  module  to  the  top  of  the  operating  system  so  that 
operating  system  calls  were  made  through  a  single  "gate"  and 
so  that  the  user  would  not  have  to  concern  himself  with 
service  codes.  The  result  was  a  very  compact,  trimmed  down, 
basic  operating  system  which  supports  multiprocessors 
performing  multiprocessing.  [Ref.  12:  pp. 13-14]  Cox 

demonstrated  MCORTEX  with  a  system  of  three  user  processes 
executing  concurrently  on  two  INTEL  iSBC86/12A 
microcomputers  connected  by  the  INTEL  MULTIBUS. 

The  specific  goals  of  this  thesis  are  to: 

1.  Test  the  generality  of  MCORTEX  by  expanding  the 
system  to  several  additional  micro-computers. 

2.  Expand  the  system  to  the  extent  necessary  to 
provide  a  means  of  dynamically  interacting  with  the 
operating  system  while  it  is  executing  so  that  efficient 
testing  of  the  multiprocessor  system  can  be  accomplished. 
Previously,  MCORTEX  had  to  be  allowed  to  "run  its  course" 


before  examining  various  structures  in  system  memory.  It 
then  had  to  be  completely  reloaded  and  reinitialized  to 
resume  execution. 

C.  STRUCTURE  OF  THE  THESIS 

Chapter  I  presents  a  general  discussion  of  the  larger, 
ongoing  effort  of  which  this  thesis  is  a  part.  It  also 
gives  a  general  discussion  of  the  background  work  that  has 
been  accomplished  regarding  the  specific  topic  of  this 
thesis,  the  MCORTEX  operating  system. 

Chapter  II  addresses  the  overall  design  philosohpy  of 
MCORTEX  and  its  functional  requirements.  Multiple  process 
communication  and  synchronization  tasks  and  techniques  are 
included.  There  is  also  a  discussion  of  process 
multiplexing  and  other  utilities  support  for  the  user. 
However,  the  discussion  is  limited,  inasmuch  as  three  prior 
theses  have  devoted  their  attention  to  the  general  design. 

Chapter  III  describes  the  hardware  architecture  of  the 
system  on  which  MCORTEX  is  demonstrated  and  why  this 
particular  micro-computer  was  chosen. 

As  the  iSBC  86/12A  is  a  developmental  system,  the  first 
part  of  Chapter  IV  outlines  the  INTEL  corporation  support 
systems  that  make  the  use  of  the  iSBC  86/12A  possible. 
Chapter  IV  then  addresses  the  detailed  design  of  MCORTEX. 
Testing  of  the  previous  version,  explanations  for  the  path 
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chosen  to  implement  enhancements,  problems  encountered,  and 
their  implications  are  discussed. 

Chapter  V  summarizes  the  testing  of  the  operating  system 
and  describes  the  new  capabilities  available  to  the  user. 
Suggestions  are  also  given  for  future  research  and  testing. 
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II.  BASIC  DESIGN  CONCEPTS 


A.  PROCESS  STRUCTURE 

Dividing  a  job  into  asynchronous  parts  and  concurrently 
executing  these  parts  as  separate  entities  offers 
significant  advantages  if  the  job  is  continuously  receiving 
input  and/or  processing  data.  In  a  single  processor  the 
benefits  are  mainly  confined  to  design  simplicity.  However, 
in  a  multi-processor  system  these  asynchronous  parts,  or 
processes,  are  essential  if  the  system  is  to  take  advantage 
of  parallel  and  pipeline  processing. 

There  are  two  elements  that,  together,  are  sufficient  to 
characterize  a  process;  (1)  the  process  address  space  and 
(2)  its  execution  point. 

The  address  space  is  the  set  of  memory  locations  that 
could  be  accessed  during  process  execution.  There  exists  a 
possible  path  to  all  the  memory  locations  in  that  space 
during  the  life  of  the  process.  It  is  this  important 
characteristic  that  allows  the  "distributed"  operating 
system  to  be  viewed  as  part  of  the  address  space  of  the 
process.  The  entire  address  space  can  be  viewed  as  having 
two  domains  of  execution,  the  user  domain  and  the  kernel 
domain.  Entry  to  the  kernel  domain  of  execution  is 
additionally  restricted  to  a  single  entry  point. 


This  enhances  design  and  ensures  a  certain  measure  of 
security.  See  Fig.  1 . 


The  execution  point  is  characterized  by  the  state  of  the 
machine  at  any  particular  time  and  consists  of  the  contents 
of  certain  machine  registers. 

By  designing  a  system  as  a  collection  of  cooperating 
processes,  system  complexity  can  be  greatly  reduced.  The 
asynchronous  nature  of  the  system  can  be  structured 
logically  by  representing  each  independent  sequential  task 
as  a  process  and  by  providing  interprocess  synchronization 
and  communication  mechanisms  to  prevent  race  and  deadlock 
situations  during  process  interactions. 


17 


If  the  processes  are  confined  to  well-defined  address 
spaces  that  do  not  overlap  then  they  would  never  interfere 
with  each  other.  Some  controlled  form  of  overlapping  of 
address  spaces  or  sharing  must  exist  if  there  is  to  be,  as  a 
minimum,  coordination  between  the  processes. 

B.  VIRTUAL  PROCESSORS  AND  SCHEDULING 

A  virtual  processor  is  an  abstraction.  It  is  a  data 
structure  that  contains  all  the  required  data  that  describes 
the  execution  point  of  a  process  at  any  given  instant. 
There  is  a  virtual  processor  for  every  process  but  only  one 
real  processor.  Each  real  processor  has  up  to  a  fixed 
number  of  virtual  processors  and  each  virtual  processor  has 
an  ''affinity"  for  a  particular  real  processor.  This  will  be 
explained  later  in  terms  of  the  Virtual  Processor  Map. 

The  virtual  processor  also  has  use  of  the  process  stack 
which  contains  the  procedure  activation  records  and  other 
necessary  data  for  the  execution  of  the  process.  In 
actuality  the  data  structure  that  represents  the  virtual 
processor  contains  a  pointer  to  this  stack.  Other  data  that 


represents 

the 

virtual  processor 

are 

"priority" 

of  the 

process  it 

is 

executing,  current 

state 

of  the 

virtual 

processor , 

and 

any  "event"  the  virtual 

processor 

might  be 

waiting  for. 

As  all  virtual  processors  have  the  same  components,  the 
data  structures  that  represent  the  virtual  processors  form 
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an  array  or  structure  called  the  virtual  processor  map 
( VPM) .  The  VPM  is  used  by  the  scheduler  to  select  the 
proper  eligible  process  to  be  executed.  After  selection, 
virtual  processor's  stack  is  used  to  restore  the  real 
processor  to  the  state  when  it  was  last  executing  that 
process.  This  selected  virtual  processor  is  now  "running" 
as  opposed  to  "waiting"  or  being  "ready"  to  run.  The  real 
processor,  which  is  a  physical  object,  is  always  running. 
In  this  case  the  real  processor  is  the  INTEL  8086. 

It  is  the  abstraction  of  the  real  processor  that  allows 
multiplexing  of  several  processes  on  a  single  processor 
resource.  The  high  level  system  calls  of  the  operating 
system  operate  on  these  virtual  processors  thus  making  the 
design  independent  of  the  configuration  of  the  hardware. 
Adding  real  processors  to  the  system,  up  to  the  bandwidth  of 
the  system  bus,  would  not  affect  the  user  except  that  he  is 
likely  to  obtain  increased  performance. 

User  services  available  via  procedure  calls  through  the 
gate  can  be  regarded  as  an  extended  instruction  set  which  is 
available  to  the  virtual  processor  but  not  the  real 
processors.  Rapantzikos  uses,  as  an  example,  the  "Await" 
operation.  It  does  not  use  real  processor  resources  but  it 
does  inhibit  the  use  of  the  real  processor  by  the  virtual 
processor.  [Ref.  11:  pp.^3-1*1*] 
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C.  MULTIPLEXING 


Multiplexing  could  also  be  called  multiprogramming  and 
it  is  facilitated  by  the  abstraction  of  the  real  processor 
described  in  the  previous  section.  The  execution  by  the 
virtual  processor  of  a  sequence  of  operations  is  actually 
performed  by  the  real  processor.  However,  the  sequential 
operations  may  be  separated  by  gaps  of  time  when  other 
virtual  processors  are  executing  a  sequence  of  operations. 
This  allows  efficient  use  of  scarce  real  processor 
resources.  Figure  2  shows  how  several  virtual  processors 
could  be  mapped  into  the  operation  sequence  of  one  real 
processor.  When  each  virtual  processor  is  executing  on  the 
real  processor  it  said  to  be  "bound”  to  the  real  processor. 
The  length  of  each  horizontal  line  represents  the  amount  of 
time  that  virtual  processor  is  bound  to  the  real  processor. 
Only  one  virtual  processor  can  be  running  at  any  point  in 
time.  However,  any  number  of  virtual  processors  can  be 
ready-to-be-scheduled  or  waiting  for  some  other  event. 
Figure  3  shows  the  possible  state  transitions  of  a  virtual 
processor . 


For  a  portion  of  the  time  that  a  virtual  processor  is 
executing,  it  could  be  in  the  kernel  domain  of  execution. 
This  implementation  uses  a  distributed  kernel  which  is 
interruptable  and  loop  free.  Thus,  the  virtual  processor 
can  be  interrupted  at  almost  any  point  in  time  and  continue 
on  the  next  time  it  is  scheduled.  It  should  be  noted  that 
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loop  free  indicates  a  condition  in  which  a  module  which  uses 
part  of  a  second  module  cannot  in  turn  be  used  or  called  by 
that  second  module. 


RUNNING 


Advance' 


Await 


WAITING 


^Scheduler 


Advance 

Preempt 


READY 


Fig. 3  Virtual  Processor  State  Transitions 


Therefore,  multiplexing  is  the  means  by  which  a  system 
which  has  more  processes  than  it  has  processors,  can 
efficiently  schedule  those  processes  and  make  effective  use 
of  the  real  processor's  time.  It  also  makes  the  design  and 


implementation  of  the  operating  system  easier  to  understand 
and  document. 

D.  MULTIPROCESSING 

In  a  multi-processor  environment,  concurrent  processing 
is  a  natural  byproduct.  The  process  structure  previously 
revealed  is  used  to  divide  a  job  into  separate  sequential 
tasks  that  can  now  be  scheduled  to  run  concurrently. 
Although  the  response  time  for  a  job  might  not  decrease, 
the  throughput  would  increase.  Therefore,  significant  gains 
in  efficiency  can  be  made. 

When  multiplexing  and  multiprocessing  are  combined,  a 
system  is  obtained  with  a  significant  throughput  advantage 
that  can  react  efficiently  to  asynchronous  events.  This 
implementation  uses  a  single,  system-wide,  preemptive 
interrupt  mechanism  to  signal  the  need  for  rescheduling  in 
the  multi-processing  environment.  Furthermore,  the  above 
requirements  reinforce  the  choice  of  the  iSBC86/12A  to 
implement  MCORTEX.  Commercially-available ,  general-purpose 
hardware  is  available  to  interconnect  the  iSBC86/12A  micro¬ 
computers  . 

It  should  be  noted  that  in  the  interest  of  keeping 
MCORTEX  small  and  fast,  virtual  processors  being  scheduled 
on  one  real  processor  will  never  be  scheduled  on  another. 
This  is  a  result  of  Cox's  work  in  symplifying  the  design  of 
MCORTEX.  Virtual  processors  have  an  ''affinity"  for  the  real 
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processor  on  which  they  were  originally  loaded.  It  must  be 
remembered  that  MCORTEX  is  for  a  real-time  multi-processor 
environment  and  scheduling  decisions  must  take  the  minimum 
time  possible.  The  memory  management  functions  that  would 
be  required  otherwise  would  degrade  the  performance  of  the 
real-time  environment. 

E.  COMMUNICATION  AND  SYNCHRONIZATION 

For  concurrent  processing,  a  job  that  is  composed  of 
sequential  and  non-sequential  tasks  is  explicitly  divided 
into  an  appropriate  structure  of  processes  that  can  run 
concurrently.  Inter-process  communication  and 
synchronization  are  necessary  for  concurrent  processing. 

It  is  the  responsibility  of  the  operating  system  to 
provide  mechanisms  for  effective  communication  between 
cooperating  processes.  There  are  two  kinds  of 
communications  that  processes  must  be  able  to  achieve. 
There  must  exist  a  way  for  processes  to  exchange  data.  This 
is  called  inter-process  communication.  There  must  also  exist 
a  method  for  processes  to  order  their  execution  in  response 
to  certain  events,  particularly  events  affecting  the  shared 
memory  status  and  validity.  Therefore,  to  utilize  the 
parallelism  and  pipelining  afforded  by  multiple  processors, 
a  mechanism  is  required  for  synchronization  between 
processes.  Rapantzikos  [Ref.  11]  made  the  decision  to  use 
the  eventcounts  and  sequencers  of  Reed  and  Kanodia  [Ref.  9]. 


This  provides  automatic  "broadcasting”  and  supports 
"parallel  signaling".  Another  reason  eventcounts  and 
sequencers  were  chosen  is  because  in  addition  to  providing 
synchronization,  a  history  of  the  jobs  execution  is 
maintained . 

The  synchronization  between  processes  is  supported  by 
the  "Await",  "Advance",  and  "Preempt"  functions.  Except  for 
"Preempt",  these  functions  operate  on  the  eventcounts.  The 
"Ticket"  function  operates  on  sequencers.  Cox 
[Ref.  12:p.26]  mentions  that  the  "Ticket"  function  applied 
to  sequencers  supports  the  exclusive  access  of  a  process  to 
a  shared  resource.  It  is  also  used  to  provide  odered  access 
to  the  resouce  on  a  first  come,  first  served  basis. 

The  number  of  times  an  "event"  has  occurred  is 
represented  by  an  eventcount.  Await  blocks  the  currently 
running  process  until  a  threshold  value  has  been  reached  for 
a  particular  eventcount.  "Advance"  increments  the  current 
value  for  a  particular  eventcount.  Thus,  "Await"  and 
"Advance"  can  be  used  to  provide  cooperation  between 
processes . 

"Preempt"  forces  the  scheduling  of  a  high  priority 
process  that  will  then  block  itself.  This  is  sometimes 
required  for  very  critical  asynchronous  processes.  However, 
if  there  still  exists  higher  priority  processes  that  are 
ready,  they  will  be  scheduled  first. 
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III.  MULTIPROCESSOR  ARCHITECTURE 


The  micro-computer  selected  to  initially  implement 
MCORTEX  is  the  INTEL  iSBC86/12A  single  board  computer  (SBC). 
It  is  based  on  the  INTEL  8086  16  bit  micro-processor. 
Detailed  descriptions  of  all  the  components  of  the  SBC  and 
the  multiprocessor  interface,  the  MULTIBUS,  can  be  found  in 
[Ref.  1]  and  [Ref.  2]. 

A.  HARDWARE  REQUIREMENTS 


1 .  Shared  Global  Memory 


Shared 

global 

memory  is  required  in 

this 

implementation 

as  the 

means  for  virtual 

processors 

to 

coordinate  their  communication  with  each 

other . 

The 

operating  system  is  resident  in  the  local  memory  of  each 
real  processor  where  it  is  a  distributed  part  of  the  add  -ess 
space  of  each  process  associated  with  that  processor. 
However,  data  concerning  all  the  virtual  processors  in  the 
multi-processor  system  exists  as  one  copy  in  shared  global 
memory.  One  of  the  reasons  for  keeping  all  virtual 
processor  data  in  one  structure  in  global  memory  is  the  way 
the  total  structure  is  operated  on  by  various  MCORTEX 
synchronization  system  calls.  Those  functions  as  well  as 
the  global  data  base  structure  will  be  detailed  in  Chapter 
IV,  Section  C. 
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2 .  Synchronization  Support 


To  prevent  concurrency  problems  in  the  shared  global 
memory,  a  software  lock  is  used  for  access  to  the  shared 
data  base.  However,  the  lock  itself  has  to  be  protected 
from  deadlock  and  race  conditions.  Therefore,  an 
indivisible  "test  and  set"  mechanism  is  required.  PL/M-86 
and  ASM86  both  support  this  protection  device.  In  PL/M-86, 
the  mechanism  is  the  built-in  procedure  "Lockset" 
[Ref.  8:pp. 12-14  to  12-15].  In  ASM86  support  comes  in  the 
form  of  an  instruction  prefix  "lock"  [Ref.  5:p.5-94].  The 
"lock"  prefix,  which  is  also  used  in  the  function  "Lockset", 
causes  the  system  bus,  the  MULTIBUS,  to  be  locked  during  the 
duration  of  the  following  instruction.  This  prevents  the 
interleaving  of  instructions  and/or  access  by  another 
processor.  Therefore,  only  one  processor  can  access  and 
change  the  global  lock  variable  at  any  one  time  if  the  above 
support  feature  is  utilized.  By  necessary  convention,  it  is 
the  responsibility  of  the  processor  who  last  had  access  to 
the  lock  variable  to  unlock  it.  Processors  are  then  assured 
of  mutual  exclusion  while  updating  the  shared  data  base.  It 
is  worth  reiterating  that  the  system  bus  is  locked  only 
during  the  testing  and  setting  of  the  software  lock  and  not 
during  the  software  restricted  access  to  the  shared  data 
base.  Normal  use  of  the  system  bus  continues  while  one  real 
processor  is  accessing  that  part  of  shared  memory  protected 
by  the  software  lock. 
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3 .  Inter-processor  Communications 


Some  method  of  communication  between  real  processors 
is  required  if  the  processes  they  are  executing  are  going  to 
be  synchronized.  In  the  asynchronous  real-time  environment, 
the  communication  will  invariably  come  in  the  form  of  an 
interrupt  mechanism.  The  iSBC86/12A  supports  many  different 
interrupt  schemes.  This  implementation  requires  a  single 
system  interrupt  that  any  real  processor  can  use  to 
"broadcast"  an  event.  Every  other  real  processor  has  to  be 
able  to  recognize  it  and  react  to  it.  This  preemptive 
interrupt  signals  to  the  other  processors  that  a  possible 
rescheduling  of  a  virtual  processor  is  necessary.  The 
specific  interrupt  structure  in  hardware  is  detailed  in 
this  chapter  in  Section  D.  The  software  mechanism  that 
decides  which  processor  should  react  to  the  broadcast 
interrupt  signal  is  detailed  in  Chapter  IV,  Section  E. 

B.  HARDWARE  CONFIGURATION 
1 .  System  Configuration 

Figure  4  shows  a  general  drawing  of  the  multi¬ 
processor  system  configuration.  The  CPU's  are  iSBC86/12A 
single  board  micro-computers  that  come  with  64K  bytes  of 
local  memory.  In  Cox's  work  an  inactive  iSBC86/12A's  memory 
served  as  the  global  memory  module  [Ref.  1 2 : p . 49  3  -  The 
module  was  replaced  in  this  implementation  with  a  32K  byte 
RAM  board  compatible  with  MULTIBUS.  Communication  with  each 


CPU  for  the  purpose  of  loading  developed  software  is  via  the 
serial  port  on  each  SBC. 


up  to  10 


Fig.  4  System  Configuration 
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2.  The  8086  Microprocessor 
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The  8086  is  well-documented  in  [Ref.  1]  and 
[Ref.  2].  This  section  is  intended  to  give  general 
knowledge  about  the  8086. 

The  8086  is  a  high  performance,  general  purpose 
microprocessor.  The  CPU  contains  an  Execution  Unit  (EU)  and 
a  Bus  Interface  Unit  (BIU).  The  two  units  operate 
independently  of  each  other.  The  EU  executes  instructions 
in  much  the  same  way  as  a  conventional  CPU.  But  the  BIU  is 
dedicated  to  fetching  instructions,  reading  operands,  and 
writing  operands  which  the  EU  is  executing  or  operating  on 
respectively.  The  BIU  also  "pipelines"  or  stacks 
instructions  in  an  internal  RAM  array  to  a  level  of  six. 
Thus,  a  majority  of  the  fetch  time  in  executing  instructions 
disappears.  The  number  of  instructions  executed  per  unit 
time  significantly  increases  and  idle  time  on  the  bus  is 
minimized . 

The  8086  has  a  16  bit  data  path  and  address  space  of 
one  megabyte.  The  CPU  gives  direct  hardware  support  to 
programs  written  in  the  high  level  language,  PL/M-86.  Those 
very  low  level  routines  that  must  be  written  in  assembly 
language  are  developed  in  ASM86.  The  object  code  modules  of 
each  can  be  linked  together  without  difficulty.  The  basic 
instruction  set  provides  for  direct  operations  on  memory,  to 
include  stack  operands.  It  provides  software  generated 
interrupts,  byte  translations  from  one  code  to  another, 
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move,  scan,  and  compare  operations  for  strings  up  to  64K 
bytes  in  length,  multiplications  and  division  of  binary 
numbers . 


The  8086  has  eight  16  bit  general  registers,  four  of 
which  are  byte  addressable.  The  remaining  four  are  index  or 
pointer  registers,  which  could  also  be  utilized  as 
accumulators  like  the  first  four.  Figure  5  shows  the 
organization  of  the  8086  registers  and  their  principal  use. 

The  8086  has  nine  status  bits  that  can  be  set  in  the 
flag  register  which  is  a  16  bit  register.  The  functions  of 
the  status  and  control  bits  are  listed  in  Figure  5.  One 
bit,  the  IF  flag  or  interrupt  flag,  has  special 
significance.  If  the  flag  is  "1"  it  enables  maskable 
interrupts.  If  it  is  "O'’  it  disables  maskable  interrupts. 
The  flag  must  be  initialized  for  appropriate  use  in  the 
operating  system.  The  IF  flag  will  be  described  in  greater 
detail  in  a  later  section. 

3.  Segmentation  and  Segmentation  Registers 

The  8086  does  not  support  the  notion  of  explicit 
segmentation.  For  example,  it  contains  no  special  hardware 
to  perform  memory  management  functions,  segment  access 
checks,  or  bounds  checking.  However,  addressing  is 
’’segment-like"  as  it  is  two-  dimensional.  All  addresses  are 
composed  of  two  parts:  the  base  and  the  offset.  8086 
programs  view  the  one  megabyte  address  space  of  the  8086  as 
a  group  of  segments  that  are  defined  by  the  application. 
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The  base  is  an  absolute  address  that  points  to  the  low 
memory  end  of  a  segment  aligned  on  16  byte  boundaries.  The 
offset  is  a  16  bit  number  that  indicates  position  from  the 
base  address.  Therefore,  any  segment  can  be  up  to  64K  bytes 
long  and  consists  of  contiguous  memory.  The  segment  base 
address  can  point  to  any  location  in  the  one  megabyte 
address  space.  As  the  base  segment  address  can  only  be  16 
bits  long,  the  low  four  bits  are  assumed  to  be  zero. 
Segments  may  overlap,  partially  overlap,  be  adjacent  to  each 
other,  or  be  disjoint. 

The  segment  registers  contain  the  various  segment 
base  addresses.  At  any  point  in  time  the  CPU  can  address 
four  segments.  The  function  of  the  segment  registers  may 
sometimes  alternalte  but  in  this  implementation  they  are 
used  in  their  default  roles.  Figure  5  applies  to  the  next 
several  paragraphs. 

The  code  segment  register  (CS)  contains  the  high  16 
bits  of  the  absolute  address  of  the  currently  executing  code 
segment.  The  register  is  used  in  conjunction  with  the 
instruction  pointer  register  (IP)  which  is  an  offset  value 
from  the  contents  of  the  CS  register.  Together,  these 
registers  are  used  in  a  similar  manner  to  the  program 
counter  of  smaller  micro-processors.  All  instructions  are 
fetched  from  this  segment  and  the  IP  always  points  to  the 


next  instruction  to  be  fetched. 


The  data  segment  register  (DS)  contains  the  starting 
address  of  the  current  data  segment  and  generally  contains 
program  constants  and  strings.  It  is  routinely  used  in 
conjunction  with  the  source  index  register  (SI)  and  the 
destination  index  register  (DI).  The  DS  register  may  be 
changed  during  execution  of  the  program  and,  normally,  each 
code  segment  will  have  an  accompanying  data  segment. 

The  stack  segment  register  (SS)  is  used  to  implement 
the  per  process  stacks  required  by  MCORTEX.  It  is  used  in 
conjunction  with  the  stack  pointer  register  (SP)  and  the 
base  pointer  register  (BP).  Rapantzikos  had  two  stacks  in 
effect  at  any  one  time  in  his  implementation,  a  kernel  stack 
and  a  user  stack  [Ref.  11:p.74].  When  Cox  simplified 
MCORTEX,  only  one  stack  remained.  As  MCORTEX  can  be  viewed 
as  part  of  the  process  address  space,  there  is  only  a  need 
for  a  per  process  stack.  The  contents  of  the  SP  register 
indicate  an  offset  in  higher  memory  from  the  SS  register 
contents.  SP  points  at  the  current  top  of  the  stack  which 
grows  towards  lower  memory  and  the  stack  base.  Therefore, 
the  initial  value  of  SP  indicates  the  bottom  of  the  stack. 
BP  is  kind  of  a  utility  marker.  The  first  time  it  is  used, 
it  points  to  the  same  location  as  SP  at  the  beginning  of  the 
stack.  If  for  some  reason,  a  group  of  arguments  are  pushed 


on  the  stack  (as  in  preparation  for  a  procedure  call),  the 
BP  contents  are  pushed  on  the  stack  and  then  BP  is  updated 
to  equal  the  current  SP  (top  of  the  stack).  In  this  way,  an 


activation  record  is  delineated. 


When  it  comes  time  to 


discard  the  arguments,  the  CPU  knows  how  far  back  down  the 
stack  to  go.  (In  actuality,  the  SP  is  updated  with  the  BP 
value  on  top  of  the  stack.  Nothing  is  ever  erased  from  the 
stack.  SP  and  BP  are  simply  constantly  manipulated.  Growth 
of  the  stack  will  overwrite  some  locations.)  Stacks  can  be 
up  to  64K  bytes  long  and,  like  all  other  segments,  can  be 
placed  anywhere  in  the  one  megabyte  address  space. 

The  extra  segment  register  (ES)  is  typically  used 
for  external  or  shared  data,  and  data  storage. 

4 .  The  1SBC86/ 12A( Single  Board  Computer) 

The  1SBC86/12A  is  a  complete  computer  capable  of 
stand-alone  operation.  It  is  used  as  the  basic  processing 
node  of  this  multiprocessor  system.  The  SBC  includes  the  16 
bit  8086  CPU,  64K  bytes  of  RAM,  a  serial  communications 
hK9terface,  three  programmable  parallel  I/O  ports, 
programmable  timers,  a  programmable  interrupt  controller, 
MULTIBUS  interface  logic,  and  bus  expansion  driver  for 
interface  with  other  MULTIBUS  compatible  expansion  boards. 
There  are  provisions  for  the  installation  of  up  to  16K  bytes 
of  ROM.  As  MCORTEX  progresses  it  is  anticipated  that  the 
operating  system  will  be  programmed  into  ROM. 

There  are  three  sets  of  connections  that  must  be 
made  to  each  SBC.  By  convention  one  single  board  computer, 
SBC  #1,  has  been  selected  to  provide  the  MULTIBUS  clock 
signal.  Switches  and  jumpers  for  extended  addressing  must 


be  set  and  there  are  three  jumpers  used  to  implement  the 


preemptive  interrupt  system.  The  system  bus  clock  is 
provided  by  jumping  the  adjacent  pins  E105  and  E106  on  SBC#1 
ONLY.  The  latter  two  sets  of  connections  are  explained  in 
the  next  two  sections. 

C.  PHYSICAL  ADDRESS  GENERATION 
1 .  General 

There  are  two  methods  to  specify  a  memory  address.  One 
is  the  absolute  or  physical  address  and  the  other  is  the 
logical  address.  There  is  only  one  physical  address  that 
will  specify  a  given  memory  location  but  there  may  be 
several  logical  addresses  equivalent  to  one  absolute 
address.  Absolute  addresses  can  range  from  0  to  FFFFFH. 
The  following  are  two  examples  of  how  the  processor 
reconstructs  absolute  addresses  from  two-dimensional  logical 
addresses : 

a.  1234:0000  b.  1200:0340 


It  should  be  noted  that  the  base  and  offset  are  held  in 
separate  16  bit  registers.  The  base  in  both  examples  is 


shifted  left  four  bits  and  then  the  offset  is  added.  A  20 
bit  address  results  which  ranges  the  entire  one  megabyte 


address  space. 

a.  1234 
12340< 

♦0000 

The  shifting  of  the  base  is 


b.  1200 
1 2000< 

+0340 

12W 

what  forces  the  alignment  of 


segments  on  16  byte  boundaries.  It  is  apparent  that  the  two 
different  logical  addresses  are  equal  to  the  same  absolute 
address.  The  above  is  an  extended  address  because  it  falls 
outside  the  range  0  to  FFFFH  or  64K  byte  range  of  a  single 
processor.  Which  processor  the  reference  is  made  to  is 
discussed  in  the  next  section. 

2.  Local  and  Extended  Addresses 

Addresses  outside  the  range  o  to  FFFFH  are  extended 
addresses  from  the  point  of  view  of  a  single  board  computer. 
As  the  other  SBC's  also  have  64K  bytes  of  local  RAM,  there 
must  be  some  way  of  designating  where  in  the  one-megabyte 
address  space  they  fall.  Locally,  the  SBC  does  not  need  or 
recognize  the  20  bit  address.  If  one  is  specified,  the  SBC 
has  to  know,  via  the  MULTIBUS,  where  to  go.  The  iBSC86/12A 
contains  jumpers  and  switches  that  allow  it  to  translate  20 
bit  addresses  into  local  memory.  If  each  SBC  is  configured 
properly,  each  64K  byte  local  RAM  could  be  given  a  unique 
identity  in  the  one-  megabyte  address  space  as  viewed  from 
the  MULTIBUS.  Those  connections  are  listed  in  the  next 
section.  Understanding  how  local  and  extended  addressing 
works,  and  how  absolute  addresses  are  formed  from  two- 
dimensional  addresses  is  important  because  the 
implementation  of  MCORTEX  on  the  ISBC86/12A  depends  on  it. 
The  next  several  paragraphs  assume  that  the  SBC’s  have  been 
configured  as  listed  above  and  that  the  full  64K  bytes  of 
RAM  is  visible  or  accessible  from  the  MULTIBUS. 
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From  the  point  of  view  of  the  monitor  currently 
resident  in  ROM  on  the  SBC,  the  designer  can  specify 
absolute  or  two-dimension  addresses.  For  example,  the 
display  command,  "D",  can  be  executed  by  typing: 

a.  .D2345  or  b.  .D0200:0345 

The  many  ways  Example  (b)  could  be  listed  have  already  been 
explained  in  Section  A.  Example  (a)  will  return  the  same 
result.  The  difference  is  noted  in  how  the  CS  and  IP 
registers  will  be  loaded  to  fetch  the  contents  at  that 
location  which,  incidentally  is  in  local  memory.  If  Example 
(a)  had  been  a  number  greater  than  FFFFH,  the  address  would 
have  been  "wrapped  around"  to  lower  memory.  For  example: 
.D12345 

would  have  returned  the  contents  at  23^5H,  as  that  was 
loaded  into  the  SI.  DS  was  assumed  to  be  zero.  However,  an 
example  such  as: 

. D 1 200 : 0345 

would  have  returned  the  contents  at  123**5H,  which  is 
external  to  the  local  memory.  In  this  implementation,  the 
address  would  have  been  on  SBC  ft  1  at  its  local  absolute 
address  of  23^5H.  SBC  #1  as  viewed  from  the  MULTIBUS,  has 
all  of  the  memory  from  10C00H  to  1FFFFH.  A  full  listing  of 
these  translations  will  be  given  in  the  next  section. 

From  the  point  of  view  of  the  HOL,  PL/M-86, 
knowledge  of  local  extended  addressing  is  also  important. 
The  compiler  represents  pointer  values  differently  depending 
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on  options  set  at  compile  time.  All  code  compiled  for 
MCORTEX  and  the  user  processes  must  be  done  with  the 
attribute  "LARGE'’ .  For  example: 

: F 1 : PLM86  PR0CESS5 . SRC  LARGE 

will  result  in  the  PLM  source  file  "PR0CES5. SRC"  to  be 
compiled.  The  attribute  "LARGE"  indicates  to  the  compiler 
that  references  outside  the  64K  byte  range  of  local  memory 
are  to  be  made,  and  therefore,  address  references  have  to  be 
represented  in  a  certain  way.  Specifically,  pointer 
variables  can  now  have  the  value  0  to  FFFFFH  and  even  if  the 
source  code  contains  an  absolute  reference,  it  will  be 
represented  in  memory  as  two  words.  The  higher  two  bytes 
will  contain  a  base  value  from  0  to  FFFFH  and  the  lower  two 
bytes  will  contain  an  offset  value  from  0  to  FFFFH.  For 
both  the  offset  and  base  the  least  significant  8  bits  are  in 
the  first  byte  and  the  most  significant  8  bits  are  in  the 
second  byte.  This  knowledge  was  used  to  implement  the 
diagnostic  monitor  process  so  that  it  could  access  any 
memory  from  any  SBC  in  the  multi-processor  system. 
[Ref.  6:pp.B-1  to  B-8]  [Ref.  7:p.5-4  and  8-1]  [Ref.  8:p.4- 
14  and  8-3] 

The  locator,  "LOC86" ,  also  makes  use  of  local  and 
extended  addresses.  The  locator  takes  an  object  module  that 
has  been  linked  with  necessary  modules  and  resolves  all 
relative  referances  into  actual  addresses.  To  maintain  the 
integrity  of  modules  during  testing  and  because  it  is 
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necessary  to  overlay  some  modules  on  top  of  each  other, 
certain  segments  are  "located"  at  specific  addresses.  The 
following  example  comes  from  the  locate  command  file 
actually  used  to  locate  the  operating  system  whose  file  name 
is  "KORE.LNK": 

L0C86  KORE.LNK  ADDRESSES ( SEGMENTS (4 
STACK( 03000H) ,& 

INITMOD_CODE( 0280 OH) ,4 
GLOBALM^DULE_DATA( 0E0000H) ) )4 
SEGSIZE( STACK ( 75H) ) 4 
RS( OH  TO  OFFFH ) 

Absolute  addresses  have  been  specified  for  two  modules  and  a 
stack  segment.  All  will  be  located  at  local  addresses 
except  for  the  global  data  base.  An  external  32K  RAM  board 
has  been  attached  to  the  MULTIBUS  to  serve  as  global  memory. 
It  will  recognize  references  from  the  MULTIBUS  from  E0000H 
to  E7FFFH.  The  output  of  this  command  is  the  executable 
code  module,  KORE,  that  could  then  be  loaded  on  all  the 
SBC's.  Each  SBC  would  have  a  copy  of  MCORTEX  in  its  local 
memory  and  each  would  "know"  where  to  go  to  find  the  global 
data  base. 

3 .  Hardware  Connections  for  Local/Extended  Addressing 
The  following  are  the  hardware  connections  needed  to 
set  up  RAM  addresses  properly  for  MULTIBUS  interface  access. 
They  consist  of  one  jumper  connection  and  eight  switch 
settings  on  a  dual-inline  package  (DIP)  called  SI.  Each 
board's  full  64K  byte  RAM  is  made  accessible  to  the  MULTIBUS 
by  setting  switches  #5  and  #6  open  on  every  SBC.  Switch  #8 
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on  SI  is  always  open.  Switches  1-4  have  to  do  with 
displacement  of  the  base  address  as  seen  from  the  MULTIBUS. 
It  is  necessary  to  only  use  switch  #1  to  indicate  a  64K 
displacement  from  the  top  of  a  selected  128K  byte  segment  in 
the  one-megabyte  address  space.  Switches  3-4  are  always 
open.  The  jumpers  select  the  128K  byte  segment  of  the  one- 
megabyte  address  space  where  the  64K  byte  RAM  will  be 
placed.  [Ref.  2:pp.2-7  to  2-9] 

Table  1.  RAM  ADDRESSESC MULTIBUS  INTERFACE  ACCESS) 


SBC  # 

Switch  #1 

Jumper  Connections 

Placement 

0 

closed 

127-128 

00000H-0FFFFH 

1 

open 

127-128 

1 0000H- 1FFFFH 

2 

closed 

125-126 

20000H-2FFFFH 

3 

open 

125-126 

30000H-3FFFFH 

4 

closed 

123-124 

40000H-4FFFFH 

5 

open 

123-124 

50000H-5FFFFH 

6 

closed 

121-122 

60000H-5FFFFH 

7 

open 

121-122 

70000H-7FFFFH 

8 

closed 

119-120 

80000H-8FFFFH 

9 

open 

119-120 

90000H-9FFFFH 

D.  INTERRUPT  HARDWARE 
1 .  Description 

As  with  most  other  micro-processors,  the  8086  does 
not  possess  the  capability  to  directly  generate  interrupts 
destined  for  other  devices.  This  characteristic  is  needed 
to  implement  preemptive  scheduling.  One  of  the  high  bits 
from  one  of  the  parallel  ports  is  used  to  initiate  the 
interrupt.  The  MULTIBUS  has  eight  interrupt  request  lines 
that  can  be  used,  INTRO  through  INTR7-  INTR4  was  arbitrarily 
The  output  bit  from  the  parallel  port  must  drive 
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the  interrupt  request  line  and  it  must  follow  convention  by 
using  a  negative-going-signal  on  the  MULTIBUS  interrupt 
request  line  to  request  interrupt  service.  A  single  input 
nand  gate  serves  to  drive  and  invert  the  signal  onto  the 
MULTIBUS.  Likewise,  the  same  interrupt  request  line  must  be 
connected  to  the  programmable  interrupt  controller  (PIC) 
which  recognizes  a  positive  or  positive-going-signal  to 
initiate  an  interrupt  sequence  with  the  CPU.  By  using  the 
single  INTR4  line,  all  SBC’s  react  to  the  interrupt  signal 
when  one  board  issues  it  (as  well  as  the  one  that  issued 
it.)  This  does  not  create  a  problem  and  it  will  be 
explained  in  the  next  chapter.  In  summary,  the  high  bit 
from  a  parrallel  port  is  used  to  broadcast  an  interrupt 
signal  onto  the  MULTIBUS  INTR4  line  which  is  in  turn 
connected  to  the  PIC. 

2.  Hardware  Connections 

Figure  6  shows  three  connections  that  must  be  made: 

E9  to  E 1 3 

E  6  9  to  E77 

E 1 37  to  El 42 

More  detailed  drawings  are  contained  in  [Ref.  2:pp.5- 

21  to  5-24], 
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Fig. 6  Hardware  Interrupt  Connections 


IV.  DETAILED  SYSTEM  DESIGN  AND  IMPLEMENTATION 


A.  STRUCTURE  OF  THE  OPERATING  SYSTEM 

The  distributed  modules  of  the  operating  system  create  a 
virtual  machine  hierarchy  which  controls  process 
interactions  and  manages  real  processor  resources.  The 
operating  system  is  not  aware  of  the  details  of  process 
tasks.  It  knows  each  process  only  as  an  entry  in  the 
virtual  process  map.  It  provides  processes  with  scheduling, 
synchronization,  input/output  services,  and  a  diagnostic 
process . 

The  operating  system  is  constructed  in  terms  of  four 
layers  of  abstraction.  Each  layer,  or  level,  builds  upon 
the  resources  created  at  lower  levels  (See  Figure  7). 

Level  0  is  the  bare  machine  which  provides  the  physical 
resources,  real  processors  and  storage,  upon  which  the 
virtual  machine  is  constructed. 

Level  I  is  the  scheduler  and  operating  system  support 
functions.  This  is  the  first  layer  of  the  software.  It  is 
closest  to  the  hardware  and  encompasses  the  major  machine 
dependent  aspects  of  the  system.  Since  several  of  its 
functions  are  directly  involved  with  the  hardware,  it  was 
necessary  to  code  some  of  it  in  assembly  language.  This 
section  also  contains  the  "starting  point  of  the  operating 


44 


erating  System  Levels 


system"  and  a  small  section  of  code  to  initialize  physical 
devices . 

Level  II  is  the  utilities/services  level.  All  user 
available  services  are  located  here.  Input  functions  were 
added  and  the  "Preempt"  function  was  corrected  and  changed 
to  reflect  the  addition  of  a  new  system  process. 

Level  III  is  the  supervisor.  It  is  essentially,  the 
Gatekeeper  module  of  Appendix  I,  and  provides  parameter 
adjustments  for  services  requested  by  the  user  and  a  single 
entry  point  link  to  the  operating  system  "Gatekeeper"  in 
Level  II. 

Three  system  processes  are  "given"  to  the  user.  They 
are  system  processes  as  opposed  to  user  processes  because 
they  are  created  by  the  operating  system.  The  initial 
process,  the  idle  process,  and  the  new  monitor  process  are 
scheduled  by  the  same  rules  as  any  user  process. 

B.  SYSTEM  DATA  BASE 

A  software  lock  is  provided  for  the  global  data  base 
used  by  the  operating  system.  It  is  called  "GLOBAL$LOCK" . 
It  has  nothing  to  do  with  any  shared  data  structures  in 
global  memory  set  up  by  user  processes,  but  only  the  system 
data  base,  which  is  resident  in  shared  global  memory. 


1 .  Virtual  Processor  Map 


The  Virtual  Processor  Map  (VPM)  is  the  major  data 
base  on  which  scheduling  decisions  are  based.  The  table  is 
partitioned  into  sets  of  virtual  processors.  There  is  one 
entry  in  the  table  for  each  virtual  processor  in  the  system 
and  one  virtual  processor  for  each  process  if  it  has  ever 
been  created.  Currently,  the  table  is  set  to  handle  ten 
virtual  processors  for  each  real  processor.  In  addition, 
the  table  can  handle  ten  real  processors.  Three  process 
entries  occur  by  default  for  the  idle,  initial,  and  monitor 
processes.  These  processes  are  created  and  initialized  by 
the  operating  system.  A  real  processor  will  have  ten 
contiguous  entries  in  the  VPM,  seven  of  which  are  available 
to  the  user.  As  the  VPM  is  an  array  of  records,  the  index 
to  each  record  or  virtual  processor  structure  is,  in  effect, 
a  unique  system  ID  for  the  virtual  processor.  Each  entry 
consists  of:  a  process  ID  given  by  the  user,  current  state 
of  the  process,  process  priority,  an  eventcount  thread,  the 
threshold  value  for  the  event  it  is  waiting  for,  and  the 
stack  segment  base  address  for  the  process.  The  virtual 
process  ID  of  FFH  and  FEH  are  reserved  for  the  operating 
system.  FFH  is  used  by  the  idle  process  and  the  initial 
process.  FEH  is  the  unique  identifier  for  the  monitor 
process . 
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2.  Eventcount  Table 


The  eventcount  table  is  for  synchronization.  It  is 
an  array  set  up  for  100  possible  entries  consisting  of  an 
event  name,  current  value,  and  an  eventcount  thread. 
Associated  with  each  entry  is  an  index.  Each  eventcount 
thread  is  the  start  of  a  blocked  linked  list.  If  the  thread 
value  is  FFH,  then  that  is  the  end  of  the  list.  Otherwise, 
is  equal  to  some  index  value  in  the  VPM.  That  VPM  entry,  or 
virtual  process,  will  be  active  and  waiting  for  a  certain 
threshold  value  for  that  eventcount.  The  VPM  entry  may 
itself  contain  another  thread  value  indicating  that  some 
other  virtual  process  is  waiting  on  the  same  event. 
However,  it  could  be  a  different  threshold  value. 
Associated  with  this  eventcount  array  is  the  variable 
"Events"  which  indicates  how  many  active  events  there  are 
currently  in  the  table. 

One  event  name,  FEH,  is  reserved  for  the  operating 
system.  It  is  used  to  block  processes  that  will  never  be 
awakened  by  the  normal  "Advance"  mechanism.  The  initial 
process  and  monitor  process  are  examples.  See  any  INIT 
module  in  the  appendicies. 

3 .  Sequencer  Table 

The  Sequencer  Table  is  used  to  support  process 
synchronization  and  ordering.  Space  is  reserved  for  100 
sequencers.  Each  entry  consists  of  a  sequencer  name  and  a 
value.  Associated  with  the  table  is  the  variable 


"SEQUENCERS”  which  indicates  the  number  of  active  entries  in 
the  table. 

4 .  Other  System  Data 

Another  structure  in  shared  global  memory  is  the 
Hardware  Interrupt  Flag  array.  There  is  one  flag  for  every 
real  processor,  so  the  maximum  size  of  the  array  is  ten. 
The  index  of  the  array  corresponds  to  the  system  unique  CPU 
number  for  each  real  processor  that  is  maintained  in  each 
local  memory. 

There  are  two  utility  variables  kept  in  the  system 
data  base;  (1)the  number  of  active  real  processors,  and  (2) 
an  array  that  keeps  track  of  the  number  of  virtual 
processors  active  on  each  real  processor.  The  index  of  the 
array  corresponds  to  the  system  unique  CPU  number  for  each 
real  processor. 

"CPU$INIT"  is  a  byte  variable  that  is  accessed  and 
incremented  once  each  time  a  real  processor  becomes  active. 
It  is  used  to  establish  the  system  unique  CPU  number  that  is 
the  key  to  the  way  all  of  the  information  in  the  system  data 
base  is  organized.  The  reason  this  method  is  used,  as 
opposed  to  the  "Ticket"  operation,  is  to  preserve  the 
hierarchy  of  the  operating  system. 
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C.  LOCAL  DATA  BASE 


The  local  data  base  for  the  operating  system  is  the 
Processor  Data  Segment  (PRDS).  It  contains  information  that 
applies  only  to  the  real  processor  on  which  it  is  resident. 
It  consists  of  the  system  unique  CPU  number,  the  index  of 
first  entry  in  the  VPM  for  that  real  processor,  the  index  of 
the  last  possible  entry  in  the  VPM  for  that  real  processor, 
a  counter  that  reflects  the  relative  amount  of  time  spent  in 
the  idle  process,  and  a  redundant  variable  that  reflects  the 
number  of  virtual  processors  currently  assigned  t:>  the  real 
processor.  This  number  is  maintained  in  shared  memory  and 
it  is  derivable  from  the  second  and  third  items  in  the  PRDS. 

D.  INTERRUPT  STRUCTURE 

The  operating  system  controls  the  multiprocessor 
environment.  A  means  of  communication  or  signaling  between 
real  processors  is  required.  A  single,  system-wide 
preemptive  interrupt  signal  is  the  vehicle  to  accomplish 
this.  It  was  arbitrarily  chosen  to  be  interrupt-request-4 
of  the  eight  available  for  use.  The  hardware  connections 
required  to  implement  the  system  interrupt  are  described  in 
detail  in  Chapter  III,  Section  D.  Software  control  is 
required  to  ensure  that  the  hardware  performs  with  certain 
characteristics  and  to  actually  issue  the  interrupt. 
Several  problems  were  encountered  in  the  testing  of  this 
part  of  the  system. 


A  brief  description  of  the  entire  interrupt  sequence  is 
in  order  first.  The  operating  system  finds,  in  the  course 
of  events,  that  one  or  more  processes  are  waiting  for  an 
event  that  the  currently  running  process  just  caused.  If 
any  of  those  waiting  processes  are  associated  with  the  same 
real  processor,  then  the  scheduler  will  simply  be  called  to 
make  a  scheduling  decision.  If  those  waiting  processes  are 
associated  with  other  real  processors,  then  the  operating 
system  has  three  things  to  do:  (1)  It  locates  the  waiting 
processes  in  the  VPM  and  changes  their  state  to  "ready",  (2) 
It  sets  the  hardware  interrupt  flag  associated  with  each 
real  processor,  and  (3)  it  issues  the  single  system  wide 
interrupt  signal  to  indicate  to  all  processors  that  a 
scheduling  may  be  in  order.  All  processors  will  execute 
their  interrupt  handler  which  in  turn  will  check  to  see  if 
their  respective  flags  are  set.  If  the  flag  is  set,  a  call 
to  the  scheduler  is  made.  If  it  isn’t,  normal  execution 
resumes.  The  adopted  convention  in  this  implementation  is 
that  the  processor  issuing  the  interrupt  never  sets  its  own 
flag.  If  it  needs  rescheduling,  the  scheduler  is  called 
directly . 

At  this  point  it  would  be  good  to  review  Figure  2  in 
Chapter  III,  Section  D.  Note  the  positions  of  the  interrupt 
driver  and  the  other  inverter.  There  is  also  a  pull-up 
resistor  on  the  INTR4  line  on  the  MULTIBUS  side  of  the 
interrupt  driver.  More  complete  coverage  of  the  hardware 
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devices  and  their  programming  is  given  in  [Ref.  3**PP*B- 
106  to  B-123]  and  [Ref.  3:pp*A-136  to  A— 1 363  for  the  PIC. 
The  best  reference  for  the  PPI  is  [Ref.  2]. 

All  of  the  initialization  software  for  the  PPI  and  PIC 
is  correct.  It  will  be  explained  at  the  end  of  this 
section.  However,  the  misunderstanding  of  one  of  those 
programmed  features  caused  the  poor  design  of  a  very  small 
but  critical  portion  of  the  operating  system.  There  are  two 
procedures  that  issue  interrupts,  "Preempt”  and  "Advance". 
Cox  arranged  the  instructions  for  issuance  of  the  interrupt 
in  the  following  manner: 

OUTPUT (P0RT$CC)  =  RESET; 

0UTPUT( P0RT$CC)  =  80H; 

In  one  prodedure  interrupts  were  disabled  during  this 
sequence  and  in  the  other  they  were  not.  Now  they  are  both 
disabled  consistently.  The  above  sequence  is  not  logical 
because  the  INTR4  line  on  the  MULTIBUS  is  not  reset  after 
being  used.  Thus,  no  one  else  can  use  it.  Other  processors 
would  not  have  their  interrupts  recognized  unless  the 
original  processor  that  sent  an  interrupt,  reset  it.  They 
could  send  it,  but  it  would  have  no  effect  on  a  MULTIBUS 
interrupt  line  already  being  held  low.  That  could  have 
disasterous  consequences.  Cox's  demonstration  of  two 
processors  with  three  processes  worked  by  accident.  The 
sequence  was  the  only  way  he  could  get  the  other  processors 
to  recognize  an  interrupt  signal.  Supposedly  both 
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processors  were  issuing  interrupts,  when  in  fact  only  one 
was.  The  demonstration  appeared  to  work  because  of  timing. 
An  interrupt  signal  causes  all  processors  to  check  the 
hardware  interrupt  flags.  Therefore,  even  if  an  interrupt 
signal  was  missed,  the  hardware  interrupt  flag  was  at  least 
set.  If  the  one  processor  that  had  control  of  the  interrupt 
request  line  could  issue  another  interrupt,  then 
rescheduling  would  occur  none  the  less.  Additionally,  the 
controlling  process  in  Cox’s  demonstration  was  ten  times  as 
long  as  the  other  two  combined  on  the  other  processor.  This 
combination  of  features  allowed  the  system  to  synchronize. 
The  moment  additional  SBC's  were  added  to  the  system  or  the 
system  was  loaded  down  with  more  processes,  it  failed  to 
synchronize  and  the  entire  system  would  idle. 

The  first  step  in  solving  the  interrupt  problem  was  to 
reverse  the  two  instructions  because  that  was  a  requirement 
for  the  system  to  operate  asynchronously.  Diagnostic 
hardware  was  used  to  determine  why  no  interrupts  were 
recognized  from  this  "correct"  sequence.  It  was  found  that 
although  the  PIC  was  programmed  to  be  edge  triggered,  the 
active  level  had  to  be  maintained  for  a  short  period  before 
the  interrupt  request  was  recognized  by  the  CPU.  In  the 
corrected  sequence,  the  interrupt  request  was  apparently 
being  removed  or  reset  too  quickly.  After  arbitrarily 
introducine  a  delay,  all  other  CPU's  recognized  the 
request.  It  is  suggested  that  an  interrupt  acknowledge 
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system  of  flags  be  set  up  so  the  interrupting  CPU  will  have 
a  positive  indication  that  interrupted  processors  reacted  to 
the  signal. 

In  testing  the  generality  of  MCORTEX  once  the  interrupt 
problem  was  tentatively  cleared  up,  additional  SBC's  were 
added  to  the  system.  It  was  found  that  an  uninitialized  SBC 
would  hold  down  the  INTR4  line.  This  will  kill  all 
communications  between  processors.  If  the  additional  SBC's 
were  loaded  with  MCORTEX  and  no  user  processes,  then  the 
system  communicated  effectively  because  the  operating  system 
would  initialize  the  PIC's  and  PPI's.  This  is  the  reason  in 
Appendix  A  that  any  SBC  with  no  user  process,  "idle  CPU's", 
are  initialized  first. 

MCORTEX  has  now  been  tested  with  four  SBC's.  One  SBC 
was  maintained  as  an  "idle  CPU".  Three  were  loaded  with 
five  processes.  The  original  three  processes  of  Cox  with 
slight  changes  were  kept.  Then  an  independent  system  of  two 
processes  was  added.  The  two  independent  systems  share  one 
of  the  SBC's.  In  addition,  the  new  system  actually 
demonstrated  the  sharing  and  passing  of  information  via 
common  memory.  Prior  demonstrations  only  tested 
syncrhonization .  To  prevent  the  system  from  scheduling 
processes  in  a  repeated  sequence,  input  was  prompted  from  a 
user.  This  new  demonstration  showed  truly  asynchronous 
processes  working  together  and  interfering  with  each  other. 


However,  this  demonstration  does  not  guarantee  the  correct 
operation  of  the  preemptive  interrupt. 

A  final  point  needs  to  be  emphasized  at  this  point.  The 
question  has  been  asked,  ’’Will  interrupt  requests  from 
different  processors  ever  overlap?"  The  answer  is  no.  They 
are  guaranteed  mutual  exclusion  because  the  system  data 
structures  are  locked  before  the  interrupt  request  is 
issued.  No  other  single  board  computer  can  issue  an 
interrupt  until  it  controls  the  lock. 

To  implement  the  interrupt  structure,  the  PIC  and  PPI 
have  to  be  initialized.  The  triggering  mode,  interrupt 
vector  table  address,  and  the  parallel  port  mode  have  to  be 
set.  The  type  (number)  of  interrupt  received  is  added  to 
the  interrupt  vector  table  control  word  and  multiplied  by  4. 
The  result  points  to  a  2-word  (4-byte)  memory  space  in  the 
interrupt  vector  table  —  called  the  interrupt  vector.  The 
interrupt  vector  points  to  the  address  of  the  intended 
interrupt  handling  procedure.  The  interrupt  vector  consists 
of  the  offset  and  code  segment  base  address  for  the 
interrupt  handler.  An  interrupt  will  cause  the  flag 
register,  CS  register,  and  the  IP  register  to  be  pushed  onto 
the  stack.  Then,  an  indirect  call  is  made  through  the 
interrupt  vector  to  the  interrupt  handler. 

Initialization  of  the  8259  PIC  must  follow  a  specific 
format  and  sequence.  It  can  require  up  to  four  interrupt 


control  words  (IWC)  for  initialization.  In  our  case,  only 
three  are  required:  IWC1,  IWC2,  and  IWC4. 

IWC1  must  go  to  port  OCOH.  It  is  13H.  It  means  edge 
triggering,  no  slave  PIC’s,  and  IWC3  is  not  required. 

IWC2  must  go  to  port  0C2H.  It  is  40H.  It  indicates 
that  the  interrupt  vector  table  starts  at  40H  x  4  which  is 
100H.  IWC4  must  go  to  port  0C2H.  It  is  OFH.  It  indicates 
8086  mode,  automatic  end  of  interrupt,  and  buffered  mode. 

The  result  of  the  initialization  is  that  in  the  case  of 
an  INTR4,  the  PIC  will  perform  the  following  operation: 

4x ( IWC2+INTR# )  =  4x ( 40H+4)  «  1 1 0H 
The  result  is  that  the  interrupt  vector  address  for  an  INTR4 
is  1 1 0H .  The  two  words  residing  at  1 1  OH  and  112H  will  be 

used  for  an  indirect  call  to  the  INTR4  interrupt  handler: 

[ 1 10H] : [ 1 12H] 

The  starting  address  of  the  interrupt  handler  must  be  loaded 
to  this  vector  address. 

There  are  three  parallel  I/O  ports.  One  bit  of  one  of 
the  ports  is  used  to  drive  the  INTR4  line.  Port  C  and  bit  7 
are  used.  See  Figure  2  for  details  on  connections.  One 
control  word  is  sent  to  port  OCEH  to  indicate  that  port  C 
will  be  used  as  an  output  port.  The  control  word  is  80H. 


E.  PROCESS  STACK 


The  per-process  stack  is  used  to  form  a  virtual 
processor  which  maintains  the  process  state  information. 
This  includes  the  current  execution  point,  the  code  and  data 
segment  base  addresses,  and  in  a  particular  instance,  all 
the  working  registers.  Since  this  stack  reflects  the  state 
of  the  real  processor  registers  at  the  time  of  execution, 
this  data  structure  represents  a  virtualization  of  the  real 
processor.  By  loading  the  stack  segment  base  location  into 
the  SS  and  restoring  the  real  processor  status  from  the 
stack  contents,  the  process  execution  can  be  continued  where 
it  last  left  off.  To  change  processes,  the  real  processor 
status  is  saved  on  the  current  process’  stack  for  future  use 
and  the  new  process’  stack  segment  is  loaded  into  SS  from 
the  VPM .  The  real  processor  status  is  then  restored  from 
this  new  stack  segment. 

A  three  word  header  is  maintained  at  the  stack  segment 
base:  stack  pointer  (SP),  base  pointer  (BP),  and 
interrupt-return-type  (INTR$RET).  This  header  is  used  to 
make  the  proper  adjustments  and  decisions  for  restoring  the 
hardware  condition  during  scheduling. 

Each  process  must  have  its  own  unique  stack.  The  per- 
process-stack  is  automatically  blocked  out  approximately  125 
words  of  user  run-time  stack. 


57 


F.  SCHEDULING 


The  scheduler  has  two  different  entry  points  and  two 
different  exit  points.  The  difference  exists  because  of  the 
different  requirements  for  saving  registers. 

A  normal  entry  call  by  a  Level  II  function  does  not 
require  any  general  registers  to  be  saved.  The  only 
register  which  must  be  explicitly  saved  on  the  stack  is  the 
data  segment  register  (DS).  At  this  time,  INTR$RET  is  set 
to  ”0”,  indicating  a  normal  scheduler  call.  The  scheduler 
executes  and  process  selection  and  initiation  take  place. 

An  interrupt  entry  call  is  made  through  the  interrupt 
handler  which  checks  the  hardware  interrupt  flags  to  see  if 
it  is  the  one  for  which  the  interrupt  is  intended.  If  so, 
all  registers  are  saved  in  a  particular  order.  INTR$RET  is 
set  to  77H,  indicating  an  interrupt  scheduler  call.  As  DS 
was  already  saved,  the  scheduler  is  entered  at  a  different 
point  to  avoid  that  instruction.  Process  selection  and 
initiation  then  take  place. 

In  the  common  code,  the  past  process'  stack  status  is 
saved  in  the  stack  heading.  Also,  the  return  type  indicator 
is  saved  in  the  stack  header  to  be  used  when  the  process  is 
ever  rescheduled.  "Getwork"  is  called  to  select  the  highest 
priority  process  that  is  ready  to  run.  The  stack  segment 
for  the  selected  process  is  returned  in  AX.  "Getwork" 
received  the  information  from  the  VPM.  The  scheduler  loads 
AX  into  the  stack  segment  register.  The  context  has 
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effectively  been  switched.  The  new  process'  stack  condition 
is  restored  and  the  return  type  indicator  is  checked  to 
ascertain  the  circumstances  of  the  process'  last  run-time 
termination.  If  the  indication  is  a  normal  return,  DS  is 
restored  and  the  process  returns  to  its  calling  point.  If 
the  indication  is  an  interrupt  return,  then  all  registers 
are  restored  and  the  process  returns  to  its  execution  point 
at  the  time  it  was  interrupted. 

The  scheduler  makes  calls  to  two  other  utility 
functions:  "RDYTHISVP"  and  "RET$VP".  "RDYTHISVP"  determines 
which  process  is  currently  running  by  calling  "RET$VP"  and 
sets  it  to  ready. 

G.  THE  GATE  AND  GATEKEEPER 

The  "Gate"  module  provides  parameter  translation  and 
adjustment  to  facilitate  processing.  It  directly  provides 
the  public  link  with  user  processes  for  access  to  system 
services.  A  call  to  the  specific  utility  function  is 
processed  in  the  "Gate'',  from  which  a  further  call  is  made 
to  the  operating  system  "Gatekeeper" , where  a  final  call  is 
made  to  the  specific  procedure  processing  the  requested 
service.  The  "Gate"  module  must  have  been  provided  the 


"Gatekeeper"  procedure's 

address  before  the 

"Gate" 

was 

compiled . 

This  address 

is 

obtained 

manually 

from 

the 

operating 

system  location 

map 

in  file: 

"K0RE.MP2" 

(see 

end 

of  App .  F) . 
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H.  USER  AVAILABLE  SERVICES 


1 .  Create  Eventcount 

A  process  cannot  assume  that  an  eventcount  it  is 
going  to  use  is  already  in  existence.  Any  process  that  will 
use  the  eventcount  must  create  it.  The  procedure  is  passed 
one  parameter:  the  name  of  the  event  to  be  created  in  the 
eventcount  table.  It  calls  "Locate  Eventcount"  to  see  if 
the  named  event  already  exists.  If  not,  it  enters  the  name 
in  the  table  and  initializes  the  entry.  It  then  increments 
the  number  of  events;  "EVENTS".  If  the  named  event  is  found 
when  "Locate  Eventcount"  is  called,  it  simply  returns  with 
no  change. 

2 .  Advance  Eventcount 

The  "ADVANCE"  procedure  increments  the  named 
eventcount  and  broadcasts  this  to  the  processes  awaiting 
this  particular  event,  via  a  thread.  (See  Chapter  IV, 
Section  C,  Subsection  2  for  an  explanation  of  the  thread.) 
To  awaken  a  process,  its  state  is  set  to  ready.  If  the 
awakened  process  is  associated  with  the  same  real  processor, 
then  the  scheduler  is  called  to  reschedule  all  eligible 
processes  (ready  processes)  for  the  real  processor.  If  the 
awakened  process  is  associated  with  another  real  processor, 
then  the  hardware  interrupt  flag  for  that  real  processor  is 
set  and  an  interrupt  is  issued. 
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3 .  Await  Eventcount 


’’Await"  is  passed  two  arguments;  (1)  the  event's 
name,  and  (2)  the  threshold  value  of  the  event  it  is  waiting 
on.  The  current  value  of  the  named  eventcount  is  checked. 
If  the  current  value  is  less  than  the  threshold  value,  the 
process  is  blocked  and  its  state  is  set  to  waiting.  The 
blocked  process  is  added  to  the  head  of  the  thread.  The 
scheduler  is  then  called  to  select  another  eligible  process 
to  run.  If  the  process  is  not  blocked,  ''Await"  executes  a 
return . 

4.  Read  Eventcount 

* 

"Read"  is  passed  two  parameter;  (1)  the  eventcount 
name,  and  (2)  a  return  pointer.  The  procedure  obtains  the 
current  eventcount  value  and  returns  it  to  the  calling 
process  by  using  the  pointer  as  a  base  for  the  value  to  be 
returned.  With  indirect  calls,  a  value  can  not  be  returned 
directly . 

5 .  Create  Sequencer 

"Create  Seq"  is  passed  the  name  of  the  sequencer  to 
be  created.  The  Sequencer  Table  is  searched  by  "locate  Seq" 
like  the  Eventcount  Table  to  see  if  it  exists.  If  it 
exists,  then  a  simple  return  is  executed.  If  it  does  not 
exist,  the  name  is  entered  into  the  table  and  the  other 
entries  are  initialized.  The  number  of  entries  in  the 
table,  "Sequencers",  is  incremented  by  one.  As  with 


eventcounts,  all  processes  that  use  a  sequencer  must  create 
it  first.  They  can  not  assume  it  has  already  been  created. 

6 .  Ticket  Sequencer 

The  "Ticket”  procedure  is  passed  two  parameters; 
(1)  the  name  of  an  already  created  sequencer  and  (2)  a 
return  pointer.  Its  purpose  is  to  obtain  a  unique 
sequential  number  for  the  named  sequencer.  The  current 
value  is  returned  via  the  base  pointer.  The  sequencer  is 
then  incremented.  With  indirect  calls,  a  value  can  not  be 
returned  directly. 

7 .  Create  Process 

"Create  Proc"  is  called  from  the  initial  process  or 
one  of  the  user  processes.  The  parameter  passed  as  input  to 
the  "Gatekeeper"  is  a  pointer.  The  pointer  is  used  as  a 
base  to  a  structure  to  overlay  the  data  parameters  supplied 
by  the  user.  These  user  supplied  parameters  are  structured 
in  the  "Gate".  The  parameters  are:  process  ID,  process 
priority,  process  stack  segment  location,  process  IP,  and 
process  CS.  CS:IP  is  the  starting  address  of  the  user 
process  and  it  is  manually  obtained  from  the  memory  map 
associated  with  the  process  (the  map  may  apply  to  several 
processes).  Once  obtained  it  is  inserted  into  the  initial 
module  that  created  it.  That  module  must  then  be 
recompiled,  relinked,  and  relocated.  A  per-process  stack  is 
established  and  initialized.  The  PRDS  table  and  number  of 
virtual  processors  on  this  real  processor  is  updated. 
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8 .  Preempt  Process 

"Preempt"  is  passed  only  the  name  of  the  process  to 
be  preempted.  It  searches  the  VPM  for  the  process  ID.  When 
found,  the  process  is  set  to  ready  and  the  scheduler  is 
called  or  the  processor  is  interrupted  depending  on  whether 
the  preempted  process  is  the  same  real  processor  or  not. 
"Preempt"  is  intended  for  high  priority  processes  that 
block  themselves  when  finished. 

"Preempt"  was  chosen  as  the  vehicle  to  implement  the 
second  goal  of  this  thesis.  Thus,  the  existing  frame  work 
of  the  operating  system  was  used  to  implement  the  "Monitor 
Process".  The  procedure  has  a  second  part  that  is  executed 
if  the  process  name  is  "FEH".  That  name  has  been  reserved 
for  the  "Monitor  Process"  which  is  described  in  the  next 
section.  The  "Monitor  Process"  is  a  high  priority 
diagnostic  tool  given  to  the  user.  Like  the  other  system 
processes,  the  "Idle  Process"  and  the  "Initial  Process",  the 
process  is  associated  with  every  real  processor.  "Preempt" 
has  to  search  each  real  processor's  set  of  entries  in  the 
VPM  to  find  each  "Monitor  Process"  and  set  each  one  to 
ready.  It  must  set  the  hardware  interrupt  flags  of  the 
other  real  processors,  but  not  its  own.  It  issues  an 
interrupt  and  all  the  other  real  processors  are  forced  into 
the  highest  priority  process,  the  "Monitor  Process".  For 
itself,  the  scheduler  is  called  and  it  goes  into  the  monitor 
process.  With  the  input  services  that  have  been  added  to 
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MCORTEX,  the  monitor  can  be  scheduled  via  "Preempt"  on  a 
regular  basis  or  by  request. 

9 .  Communications  with  Console 

ASCII  output  is  by  single  character  or  line.  "Out 
Char"  is  given  a  single  byte  value  and  "Out  Line"  is  given  a 
pointer  to  the  beginning  of  a  string.  The  string  should  end 
in  "%"  which  will  stop  output.  Any  ASCII  output  can  be 
stopped  at  the  CRT  by  a  "~S"  which  also  freezes  the  process. 
ASCII  output  is  resumed  with  a  "*Q".  This  ability  is  useful 
to  freeze  diagnostic  output  for  study. 

ASCII  input  is  by  single  character  and  it  is  not 
echoed.  "In  Char"  could  easily  be  used  to  fill  a  buffer  for 
line  input.  Once  "In  Char"  has  been  invoked,  the  procedure 
waits  for  the  character.  An  additional  service  should 
probably  be  added  that  does  not  wait. 

Hexadecimal  input  and  output  exists  for  byte  and 
word  values  in:  "Out  Num" ,  "Out  Dnum" ,  "In  Num" ,  and  "In 
Dnum" .  Output  is  interruptable .  Input  is  echoed  for  both 
byte  and  word  values.  Illegal  characters  are  ignored. 

I.  SYSTEM  INITIALIZATION  AND  SYSTEM  PROCESSES 
1 .  System  Initialization 

The  starting  address  for  initiating  the  operating 
system  is  found  in  the  operating  system  memory  map  in  file: 
"K0RE.MP2"  (See  App .  F).  It  is  usually  100:30.  When  the 
system  is  initiated,  by  issuing  the  monitor  command, 


. G 1 00 : 30<cr>  ,  the  operating  system  initialization  routine  is 
executed.  The  PPI  and  PIC  are  initialized  as  discussed  in 
Chapter  IV,  Section  E. 

Next  a  unique,  sequential  number  is  obtained  and 
used  to  initialize  the  ,,CPU$NUMBER  in  the  PRDS  table  for 
this  processor.  This  is  the  identity  of  this  real  processor 
and  is  the  key  to  the  location  of  entries  in  the  VPM.  The 
PRDS  is  further  initialized  by  using  the  "CPU$NUMBER"  to 
calculate  the  beginning  and  ending  locations  in  the  VPM  for 
this  processor  and  by  setting  the  number  of  virtual 
processors  on  this  real  processor  to  three. 

The  VPM  is  then  initialized  for  the  three  system 
processes.  The  number  of  real  processors  in  the  system, 
"NR$RPS" ,  is  updated  to  indicate  another  processor  has  been 
added  to  the  system.  ( "CPU$INIT"  could  have  been  used.) 
All  hardware  interrupt  flags  are  cleared  and  the  scheduler 
is  called. 

The  stack  used  during  the  initialization  is  the 
kernel  stack,  which  is  located  at  the  location  specified  in 
the  execution  of  "LOC86”  (see  App.  F).  In  this  case,  the 
kernel  stack  is  at  3000H  and  its  size  is  75H.  In  order  to 
initialize  the  stack  segment,  SS,  and  stack  pointer,  SP,  the 
initialization  routine  code  cannot  be  in  a  procedure  block. 
It  must  be  coded  as  the  main  routine  operating  system 
("KORE”)  module.  Neither  the  initialization  routine  or  the 
kernel  stack  is  used  again  during  the  system  run  time. 
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2.  Process  Initialization 


When  the  operating  system  initialization  routine  is 
completed,  it  calls  the  scheduler.  The  scheduler  selects  the 
highest  priority  ready  process  to  run.  Initially,  that  will 
always  be  the  initial  process.  This  process  is  intended  to 
be  the  vehicle  by  which  the  user  processes  are  established 
in  the  tables  of  the  operating  system.  It  is  assumed  that 
the  programs  are  already  loaded  in  memory  as  characterized 
in  the  creation  specification. 

During  the  linking  and  locating  of  the  operating 
system,  the  file,  "INITK",  was  included  and  located  at 
2800H.  This  file  acts  as  a  dummy  to  establish  the  space  and 
starting  location  for  the  operating  system’s  reference.  It 
is  a  valid  initial  process  module,  but  it  will  normally  be 
overlayed  by  an  "INIT"  procedure  modified  and  loaded  by  the 
user.  The  user  must  locate  his  "INIT"  module  at  2800H  in 
this  implementation. 

The  "INIT"  file  must  fit  the  prescribed  format  as 
provided  and  enough  space  must  be  reserved  for  it  by  the 
locate  command.  The  user  only  modifies  one  area  of  the 
file.  He  provides  the  absolute  parameters  required  in  the 
call  to  the  "Create  Proc"  procedure.  One  call  must  be  made 
for  each  process.  The  user  can  create  up  to  7  processes  per 
real  processor  for  a  system  total  of  70. 

Also,  of  concern  to  the  user,  is  the  intended  stack 
location.  At  the  desired  stack  location,  the  user  must 
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allow  enough  space  for  a  stack  of  120H  bytes.  The  user 
process  must  be  coded  in  procedure  blocks  so  the  stack 
segment,  SS,  and  the  stack  point,  SP,  will  not  override  what 
is  provided  by  the  operating  system.  The  user  process 
procedure  block  should  have  the  attribute  "public"  so  that 
the  address  can  be  obtained  from  the  location  map  to  be  used 
as  parameters  for  process  creation.  See  Section  I, 
Subsection  7  of  the  chapter. 

The  "INIT"  process  will  create  the  processes 
specified,  then  block  itself  with  a  call  to  "Await".  This 
allows  the  newly  created  processes  to  be  scheduled  and  run 
according  to  their  priorities. 

3 .  The  Idle  Process 

The  idle  process  has  the  lowest  priority  of  any 
process.  It  is  selected  by  the  scheduler  only  if  there  are 
no  other  eligible  processes  (i.e.,  all  others  are  blocked). 
When  selected,  its  only  function  is  to  update  the  counter 
contained  in  the  real  processors  own  PRDS  table  at 
approximately  one  second  intervals.  Thus,  a  rough  measure 
of  time  is  obtained  when  this  real  processor  is  doing  no 
useful  work. 

4 .  The  Monitor  Process 

This  high  priority  system  process  is  scheduled  by 
all  processors  at  the  same  time.  No  matter  which  process 
preempts  the  "Monitor  Process",  the  entire  system  will  be 
"put  to  sleep".  The  entire  system  address  space  is  then 
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accessible  from  the  serial  port  of  any  processor 
simultaneously.  Each  processor  exits  the  "Monitor  Process" 
individually  and  in  any  order.  The  user  could  leave  an 
"idle  CPU"  in  the  monitor.  However,  the  user  must  realize 
that  data  could  be  changing  while  he  is  accessing  it.  The 
system  would  then  resume  normal  scheduling. 

A  primary  motivation  for  implementing  the  "Monitor 
Process"  was  that  there  was  no  way  to  examine  memory  for 
diagnostic  purposes  until  after  the  system  had  run  its 
course  or  the  designer  stopped  it  arbitrarily.  Now,  memory 
can  be  examined  on  a  synchronized  basis  with  the  occurence 
of  specified  events.  A  record  of  transactions  with  the 
process  can  also  be  secured  to  a  line  printer 
simultaneously . 

Appendix  C  contains  a  summary  of  the  monitor 
commands  which  closely  mimic  those  of  the  resident  monitor. 

J.  METHODS  AND  FACILITIES 

Software  development  for  MCORTEX  was  accomplished  on  an 
Intellec  MDS  800  developmental  system  under  the  INTEL 
Systems  Implementation  Supervisor  (ISIS-II).  The  MDS  800  is 
based  on  the  8080  microprocessor.  ISIS-II  is  a  diskette 
operating  system.  The  MDS  system  has  two  double  density 
disk  drives.  Object  code  for  the  8086  is  developed  on  the 
MDS  800  and  down  loaded  to  the  i SBC86/ 1 2A ' s .  Readers 
unfamiliar  with  the  ISIS-II  system  are  refered  to  [Ref.  3]. 
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However,  all  source  code  was  developed  using  the  text 
editor,  TED,  from  Digital  Research  Inc. 

There  are  two  double  density  eight  inch  diskettes 
necessary  to  continue  implementation  of  or  to  examine 
MCORTEX  and  test  process  source  code.  KLINEF.A1  contains 
module  source  code,  relocatable  code  modules,  executable 
code  modules,  memory  maps  and  basic  ISIS-II  utilities. 
KLINEF.B1  contains  all  the  module  processing  programs  such 
as  the  linker,  locator,  assembler,  and  compiler.  Because, 
these  programs  are  large,  they  are  stored  on  a  separate 
diskette.  Output  from  the  module  processing  programs  goes 
to  KLINEF.A1.  Appendix  C  contains  annotated  directory 
listings  of  both  diskettes. 

External  hardware  connections  required  to  set  up  the  MDS 
800  and  SBC's  in  order  to  facilitate  communication  are 
detailed  in  Appendices  A  and  B.  Appendix  A  is  a  detailed 
"pre-power-on”  and  "post-power-on"  checklist  to  load  the 
single  board  computers.  Appendix  B  contains  a  drawing  that 
describes  the  physical  make-up  of  the  transfer  hardware. 
Cox  cites  a  five  wire  RS232  cable  in  [Ref.  12:p.45]. 
However,  only  three  are  required.  See  Appendix  B  for 
further  details. 

1 .  The  PL/M-86  Compiler 

As  software  modules  must  be  compiled  individually, 
no  command  files  for  use  with  the  ISIS-II  utility,  SUBMIT, 
were  established  [Ref.  3:pp-3-13  to  3-14].  The  following 
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controls  were  found  to  be  useful:  PRINK :LP:),  NOPRINT, 
CODE,  and  LARGE.  The  use  of  the  control  LARGE  is  mandatory 
as  discused  earlier.  It  causes  the  compiler  to  represent 
addresses  in  such  a  way  that  the  whole  megabyte  range  of  the 
8086  can  be  used.  See  Chapter  III,  Section  C,  Subsection  2 
for  additional  information  on  addressing  modes.  The 
following  references  contain  more  details  concerning  run¬ 
time  representations  by  the  compiler  when  the  LARGE  control 
is  used:  [Ref.  7:pp*3-13  to  3-14,  5-1  to  5-5,  8-1].  Other 
pertinent  references  concerning  the  compiler  are:  assembly 
language  module  linkage  [Ref.  7:pp.9-1  to  9-3]  and  the 
preemptive  interrupt  process  [Ref.  7:pp.10-1  to  10-4]. 

2.  Link86( Linker ) 

LNK86  takes  object  code  modules,  combines  them,  and 
resolves  external  references  from  each  individual  module. 
The  resulting  relocatable  file  has  the  default  file 
extension,  ”.LNK”.  No  controls  are  necessary.  Two  command 
files,  "LNKK.CSD"  and  ’’LNKP.CSD”,  which  have  been 
established  can  continue  to  be  used  in  the  future. 
■’LNKK.CSD”  contains  the  commands  to  link  all  the  object  code 
modules  that  compromise  MCORTEX.  ’’LNKP.CSD"  contains  the 
three  commands  that  link  the  user  modules  into  the  three 
modules  that  will,  after  further  processing,  be  loaded  onto 
three  SBC’s.  Complete  error  listings  are  given  in 
[Ref.  4:App.  A]. 
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3 .  Loc86( Locator ) 


Use  of  the  locator  is  a  little  more  involved.  This 
program  assigns  addresses  to  the  relocatable  code  modules 
that  come  from  the  linker.  It  requires  knowledge  of  how 
modules  are  organized  in  the  system  address  space  both  by 
the  user,  and  by  the  operating  system  designer. 
[Ref.  4:Chapter  4]  gives  the  best  description  of  how  the 
locator  handles  modules.  The  two  command  files,  "LOCK.CSD" 
and  "LOCP.CSD" ,  established  for  the  locator  will  also 
provide  most  of  the  knowledge  required  to  locate  user  code. 
Eventually,  after  more  extensive  testing,  MCORTEX  will  be 
tuned  and  compressed  to  the  maximum  extent  possible  so  that 
it  can  be  put  on  EPROM.  Currently,  modules  are  well 
dispersed  to  facilitate  design  and  development. 

One  type  of  output  file  from  L0C86  is  the  " . MP2" 
memory  map  file.  In  addition  to  valuable  diagnostic 
information,  several  critical  pieces  of  information  from 
these  file  are  necessary  for  the  correct  operation  of 
MCORTEX  and  the  user  process.  There  are  essentially  three 
items;  (1)  the  location  of  the  gatekeeper,  (2)  the  starting 
addresses  of  user  code,  and  (3)  the  starting  point  of  the 
operating  system.  Warning  remarks  in  the  source  code  detail 
what  and  where  these  items  are.  In  addition,  later  sections 
in  this  chapter  will  discuss  those  items. 

Upon  examining  any  ".MP2"  file,  a  ''WARNING  56:..." 
will  at  certain  times  appear.  For  example,  see  K0RE.MP2  in 
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Appendix  E.  This  is  caused  by  intensionally  overlaying  some 
kind  of  segment  in  space  that  was  previously  reserved.  The 
warning  should  not  cause  too  much  concern.  See  the  memory 
map  from  P03  in  Appendix  K  for  a  more  clear  cut  example. 
The  effort  in  the  last  example  was  to  prevent  any  code  being 
put  next  to  the  initial  process  code.  See  [Ref.  4:Chap.  3] 
for  more  details  on  the  controls  available  to  the  LOC86 
command . 
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V.  CONCLUSIONS 


The 

pricipal  goals 

of 

this  thesis 

were  met. 

The 

generality  of  MCORTEX 

was 

tested  and  demonstrated. 

Two 

problems 

were  uncovered: 

(1) 

The  interrupt 

mechanism 

does 

not  appear  to  be  totaly  satisfactory  and  (2)  the  issue  of  an 
inactive  SBC  bringing  down  the  system  will  eventual  have  to 
be  addressed.  The  system  was  demonstrated  with  four  single 
board  computers  and  there  appears  to  be  no  reason  why  the 
additional  six  cannot  be  added.  Actual  synchronized  sharing 
of  data  was  demonstrated.  Two  independent  user  systems 
operating  simultaneously  was  demonstrated.  The  system  was 
prevented  from  scheduling  processes  in  a  fixed  sequence  by 
introducing  user  interaction.  User  input  services  have  been 
added  to  MCORTEX  and  a  method  was  found  within  the  existing 
framework  of  the  operating  system  to  incorporate  dynamic 
interaction  with  the  operating  system  itself.  The  total 
address  space  is  now  accessible  from  any  single  board 
computer  for  system  debugging  and  examination. 
Additionally,  the  operating  system  can  be  continued  without 
reinitializing  the  system.  ''Preempt”,  which  had  never  been 
tested,  is  now  used  to  evoke  the  "Monitor  Process”. 

Three  possible  problem  areas  were  cited  by  Cox  in  his 


thesis . 

The 

cause  of  the 

first  one  was 

acertained.  A 

weakness 

in 

the  interrupt 

system  has 

been  clearly 
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identified.  A  possible  problem  with  the  eventcount  thread 
was  not  examined  as  it  did  not  immediately  impact  on  the 
primary  goals  of  the  thesis.  The  third  problem  cited  was 
the  inablitiy  to  stop  and  restart  the  system  without 
reinitializing  all  code.  That  ability  now  exists  by 
selectively  preempting  the  ’’Monitor  Process". 

Future  research  with  MCORTEX  should  concentrate  on 
taking  precise  timing  and  performance  measurements  while  the 
system  is  heavily  loaded  down.  The  second  possible  problem 
cited  by  Cox,  mentioned  above  will  also  have  to  be  examined. 
The  process  stacks  should  also  be  examined  to  dynamically 
confirm  capacity  usage  as  there  are  no  definitive 
guidelines  upon  which  to  base  stack  size.  A  system  of 
hardware  interrupt  ackowledge  flags  will  probably  have  to  be 
set  up  to  stregthen  the  preemptive  interrupt  system. 


APPENDIX  A 


SYSTEM  INITIALIZATION  CHECKLIST 

I .  PRE-POWER-ON  CHECKS 

A.  SBC's  have  address  translation  switches  and  jumpers 
correctly  set. 

B.  SBC's  have  3  interrupt  jumpers  set. 

C.  SBC  #1  has  MULTIBUS  clock  jumper  set. 

D.  No  other  SBC  has  MULTIBUS  clock  jumper  set. 

E.  SBC's  and  common  memory  board  full  seated  in  odd 
slots  of  MULTIBUS  frame. (RAM  board  can  be  in  any  slot.) 

F.  Remove  all  serial  CRT  cables  from  SBC's. 

G.  J2  26  pin  edge  connector  on  transfer  cable  can  be 
hooked  up  to  one  of  the  SBC  serial  ports  at  this  ooint. 

H.  If  RS232  transfer-cable  has  a  "null  modem"  switch  on 
it,  set  it  to  "null  modem".  This  transposes  wires  2  and  3. 
The  switch  may  alternately  be  marked  "computer  to  computer" 
and  "computer  to  terminal".  Set  to  "computer  to  computer". 
It  should  always  remain  in  this  position. 

I.  Connect  other  end  of  transfer  cable  (25P  RS232 

connector)  to  2400  baud  CRT  port  of  the  MDS  system. 

J.  Connect  any  CRT  to  the  9600  baud  TTY  port  of  MDS 
system. 

K.  Ensure  CRT  is  set  to  9600  baud. 

L.  CRT  that  will  be  connected  to  SBC's  should  be  set  to 
9600  baud.  Thi3  step  is  not  mandatory,  but  recommended. 
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M.  Each  CRT  that  will  be  connected  to  SBC  should  have 
RS232  cable  hooked  up  to  serial  port.  It  should  lead  to 
flat  25  wire  ribbon  and  J2  connector  so  it  can  eventually  be 
hooked  to  serial  port  of  the  SBC's. 

II.  POWER  ON  PROCEDURES 

A.  Turn  power-on  key  to  ON  at  MULTIBUS  frame. 

B.  Press  RESET  near  power-on  key. 

C.  Turn  power  on  to  all  CRT's. 

D.  Power  up  MDS  disk  drive. 

E.  Power  up  MDS  terminal  (If  not  already  done). 

E.  Turn  power-on  key  to  ON  at  MDS  CPU  (front  panel, 
upper  left  corner). 

F.  Line  printer  can  be  turned  on  at  any  time. 

III.  BOOT  UP  MDS 

A.  Place  system  diskette  in  drive  0.  Executable 
modules  and  SBC861  can  be  on  another  diskette  in  drive  1. 

B.  Push  upper  part  of  boot  switch  in  (It  will  remain 
in  that  position ) . 

C.  Press  reset  and  release. 

D.  When  interrupt  light  if 2  lights  on  front  panel,  press 
space  bar  on  console  device. 

E.  Reset  the  boot  switch  by  pushing  lower  part  of 
switch . 

F.  ISIS-II  will  respond  with 

G.  Line  printer  can  be  turned  on  at  any  time. 


IV.  LOAD  MCORTEX  AND  PROCESS  MODULES 

A.  Type  "SBC86l<cr>" . 

B.  If  "»CONTROL»"  appears,  SBC  was  not  able  to  set  its 
baud  rate.  Press  RESET  on  MULTIBUS  frame  and  start  over. 
Once  set,  all  SBC's  should  accept  modules. 

C.  If  "Bad  EMDS  connection"  appears,  you  will  not  be 
able  to  continue.  Check  connections.  Make  sure  diskette  is 
not  write  protected.  Push  RESET  at  frame.  Try  again. 

D.  SBC861  will  prompt  with  It  will  now  accept  any 

monitor  command. 

E.  Type  "L  KORE" .  Wait  for 

F.  Type  "L  <process  filename>".  Wait  for 

G.  Type  "E"  to  exit  SBC861.  It  is  not  a  good  policy  to 
switch  the  transfer  cable  to  another  SBC  serial  port  with 
out  exiting  SBC861 . 

H.  Switch  transfer  cable  to  next  SBC.  Go  to  A. 

V.  RUN  MULTIPROCESSOR  SYSTEM 

A.  Disconnect  transfer  cable  from  last  SBC  loaded. 

B.  Connect  J2  connector  from  each  CRT  to  an  SBC  serial 
port . 

C.  After  all  CRT's  connected,  push  RESET  on  frame  to 
brake  baud  rate. 

D.  On  each  CRT  press  "U"  to  obtain  monitor.  Will 
respond  with 


E. 


Type  "G100:30<cr> 


at  each  terminal  to  start 


MCORTEX.  If  one  of  the  SBC's  is  running  only  MCORTEX  and  no 
user  processes,  start  it  first. 
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APPENDIX  B 


SYSTEM  INITIALIZATION  HARDWARE  CONNECTIONS 

The  following  page  contains  a  drawing  of  the  hardware 
connections  required  for  transfering  code  developed  on  the 
MDS  800  to  the  single  board  computers.  The  transfer  cable 
has  two  parts,  an  RS232  cable  and  a  25  wire  ribbon. 

The  RS232  cable  has  a  25P  connector  that  mates  with  the 
2400  baud  25S  connector  on  the  back  panel  of  the  MDS  CPU. 
The  other  end  is  a  25S  connector  that  will  mate  with  the  25 
wire  ribbon. 

The  ribbon  has  a  25S  connector  for  attachment  to  the 
cable.  The  other  end  is  a  26  pin  edge  connector  that  will 
mate  with  the  J2  junction  on  the  single  board  computer.  J2 
is  the  serial  port.  The  26th  pin  is  left  unconnected  on  the 
edge  connector. 
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Fig.  8  Down  Load  Cable  Connections 


APPENDIX  C 


ANNOTATED  DIRECTORY  LISTING  FOR  KLINEF . A 1 


NAME  .EXT  REMARKS 


ATTRIB 


ISIS-II  Utility.  See  Ref.  3 


COPY 

tf 

M 

II 

•f 

DELETE 

If 

ff 

If 

•» 

DIR 

If 

tl 

II 

If 

FIXMAP 

If 

II 

tl 

tl 

HDCOPY 

I* 

•1 

t» 

If 

IDISK 

»t 

If 

t» 

tt 

LIB 

f! 

tf 

It 

It 

LIB86 

If 

If 

It 

If 

RENAME 

II 

If 

II 

II 

5U I RMTT 

ff 

tf 

It 

•f 

TED 

LNK 

LNKP 

LOCK 

LOCP 

GATE 

GATE 

GLOBAL 

GLOBAL 

INIT1 

INIT2 

INIT3 

INIT1 

INIT2 

INIT3 

INITK 

INITK 

KORE 

KORE 

KORE 

KORE 

LEVEL  1 

LEVEL  1 

LEVEL2 

LEVEL2 

PROC1 

PROC1 

PROC2 

PROC2 

PROC3 

PROC3 

PROC4 

PROC4 


.  CSD 
.  CSD 
.CSD 
.CSD 
.SRC 
.OBJ 
.SRC 
.OBJ 
.SRC 
.SRC 
.SRC 
.OBJ 
.OBJ 

•  OBJ 
.SRC 

•  OBJ 
.LNK 


.  MP 1 
.  MP2 
.SRC 
.OBJ 
.SRC 
.OBJ 
.SRC 
.OBJ 
.SRC 
.OBJ 
.SRC 
.OBJ 
.SRC 
.OBJ 


Text  editor.  Not  a  ISIS-II  utiltiy. 

Links  MCORTEX  modules.  Command  file. 

Links  process  modules.  Command  file. 

Locates  MCORTEX  relocatable  file.  Cmd  file. 
Locates  process  relocatable  files.  Cmd  file. 
User  gate  module  source  code. 

"  "  "  object  " 

MCORTEX  global  data  base  source  code  module. 

"  **  "  "  object  "  " 

User  initial  process  source  file  for  1st  CPU 
"  ”  "  ”  "  for  2nd  CPU 

"  "  "  ”  ”  for  3rd  CPU 

Compiler  object  code  output  file  for  1st  CPU 
'*  "  ••  "  "  •'  2nd  CPU 

"  ”  "  •*  "  "  3rd  CPU 

MCORTEX  initial  process  source  code  module. 
MCORTEX  initial  process  object  code  module. 
MCORTEX  relocatable  code  file. 

MCORTEX  executable  code  module. 

Linker  map  file. 

Locator  map  file. 

MCORTEX  levell  source  code  module. 

"  ”  object  " 

”  level2  source  "  " 

"  ■'  object  " 

User  process  1  source  code 

"  object  " 


I? 

If 


2  source 
"  object 

3  source 
"  object 

4  source 


object 


PR0C5 

•  SRC 

"  "  5  source 

»t 

PR0C5 

.OBJ 

"  object 

»t 

P01 

.  LNK 

User  relocatable 

code 

file  for  CPU 

1 . 

P01 

"  executable 

tt 

ff  ft  ff 

It 

P02 

.  LNK 

"  relocatable 

If  ff  t* 

2. 

P02 

"  executable 

ft  it  If 

M 

P03 

.LNK 

"  relocatable 

»t 

ff  if  i* 

3’ 

P03 

"  executable 

ft 

ff  M  if 

if 

P01 

.MP1 

Linker  map  file. 

P02 

.  MP1 

»»  It  if 

P03 

.MP1 

ff  »»  it 

P01 

.  MP2 

Locator  "  "  . 

P02 

.  MP2 

t»  ti  »f 

P03 

.  MP2 

M  *t  ff 

SBC861 

SBC  down  load  program 

* 

SCHED 

.ASM 

Scheduler  &  interrupt 

handler  assembly 

language  source 

code 

nodule . 

SCHED 

.OBJ 

Scheduler  4  interrupt 

handler  object 

code  module. 


ANNOTATED  DIRECTORY  LISTING  FOR  KLINEF.B1 


NAME  .EXT  REMARKS 


COPY 

DELETE 

DIR 

SBC861 
SBCIOC .LIB 
SBCIOS . LIB 
SBCIOL.LIB 
SB957A.020 
ASM86 

ASM86  .OVO 
ASM86  .OV1 
ASM86  . OV2 
PLM86 

PLM86  .OVO 
PLM86  .OV1 
PLM86  . OV2 
PLM86  . OV3 
PLM86  .OV4 
PLM86  .OV5 
PLM86  .OV6 
PLM86  .LIB 
LINK86 
LINK86 . OVO 
LOC86 


ISIS-II  utility. 

ff  ff 

t»  »« 

MDS  to  iSBC86/12A  down  load  program. 


ASM86  assembler. 


PL/M-86  compiler. 


Object  code  linker. 
Relocatable  code  locater. 


APPENDIX  D 


SBC861  &  The  MCORTEX  MONITOR 


No  up  to  date  information  on  the  down  load  program  and 
the  monitor  for  the  SBC's  was  found.  There  is  related 
material  in  [Ref.  1]  and  [Ref.  3:pp.B-179  to  B-1831  only. 
The  ”E"  (exit)  and  "L"  (load)  commands  are  discussed  in 
Appendix  A.  The  remaining  commands  are  the  same  as  if  you 
were  dealing  with  the  SBC  monitor.  Only  the  form  using  the 
two  dimensional  address  is  shown  below.  Only  significant 
digits  need  be  displayed. 


Command 


Meaning 


. dzzzz : zzzz<cr >  Display  contents  at  zzzz:zzzz. 

.dzzzz : zzzz#zzzz<cr>  Displays  contents  starting  at 

zzzz:zzzz  for  zzzzH  bytes, 
.dxzzzz: zzzz<cr>  Same  rules  as  above, except 

byte  are  decoded  in  to  basic 
assembly  language. 

. gxxxx : xxxx<cr>  kB8dltS?tlnixJ?tSiSR . xxxx :xxxx 

.x<cr>  Displays  current  register 

contents . 

.c[name]<cr>  Change  register  contents. 

.szzzz:zzzz  Subsititute  at  zzzz:zzzz. 

If  followed  by  " , " ,  next  byte  is 
displayed  for  possible 
substitution.  <cr>  causes 
prompt  for  byte  value. 
or  <cr>  causes  change  to  take 
effect  with  above  rules  still 
applying . 


.gxxxx  :xxxx<cr> 
.x<cr> 

.c[name]<cr> 

. szzzz : zzzz 


84 


The  MCORTEX  MONITOR 


The  MCORTEX  monitor  closely  parallels  the  command 
structure  of  the  SBC  monitor.  There  are  only  three 
commands;  display,  substitute,  and  exit.  Commands  are 
evaluated  on  a  character  by  character  basis  instead  of 
waiting  until  a  buffer  is  filled.  Once  you  are  in  the 
monitor,  illegal  characters  are  not  accepted  and  pressing 
the  wrong  key  will  have  no  effect.  If  you  enter  the  wrong 
command  or  address,  follow  through  to  start  over.  The  full 
two-dimensional  8  hex  character  address  must  be  specified, 
key.  All  commands  are  prompted  for  by  a  See  Chapter 
IV. 


Command 


Meaning 


.dOOOO : 0000<cr> 
#FF 


.30000:0000 


<cr> 


00 


.e 


Display  one  byte  at  0000:0000. 

is  automatically  inserted. 
Display  FFH  bytes  starting  at 
0000:0000.  FFH  is  maximum.  Once 
last  digit  entered,  formated 
display  starts. 

Spa'^e  cause  current  contents  to 
be  displayed  as:  "xx-". 

Casues  offset  to  be  incremented 
and  new  address  deisplayed.  Same 
rules  apply. 

Returns  monitor  command  prompt. 
After  a  space  and  the  contents 
desired  are  displayed  as:  ”xx-". 
the  same  or  a  new  byte  value  must 
be  entered. 

A  will  continue  the  sequence  to 
the  next  location.  A  <cr>  will 
terminate  it  and  return  the  prompt. 
Return  the  SBC  to  MCORTEX.  This  can 
be  done  in  ANY  order  or  not  all  for 
a  particular  terminal. 


APPENDIX  E 


LEVEL  II  —  MCORTEX  SOURCE  CODE 

All  of  the  source  code  in  LEVEL  II  is  contained  in  file: 
LEVEL2.SRC.  It  is  compiled  with  the  LARGE  attribute.  It  is 
one  of  the  relocatable  code  modules  in  file:  KORE.LNK.  It 
is  part  of  the  executable  code  module  in  file:  KORE.  A 
memory  map  for  this  module  is  located  at  the  end  of  Appendix 
F.  All  operating  system  calls  available  to  the  user  are 
located  in  this  module. 
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/*  FILE: 
VERSION: 
PROCEDURES 
DEFINED: 


LEVSL2.SEC 
KLINEF  5-20-82 


GATS$KEEPER 

READ 


CREATE$EVC 

AWAIT 


ADVANCE 

TICKET 

OUT$CEAR 

OUT$NUM 

SEND5CHAR 

RECV$CHAR 

I N$  NUM 

IN$HEX 


PREEMT 

CREATS$PROC 

0UT$LINE 

OUT$DNUM 

OUTSHSX 

IN  $CHAR 

IN$DNUM 


REMARKS:  !!!  CAUTION  ! ! !  It!  CAUTION  It!  !!!  CAUTION  1 1! 

IF  NEW  USER  SERVICES  ARE  ADDED  TO  THIS  MODULE 
OR  CHANGES  ARE  MADE  TO  EXISTING  ONES,  MAKE 
SURE  THE  LOCATOR  MAP  (FILE:  KORE .M?2)  IS  CHECK¬ 
ED  TO  SEE  IF  THE  LOCATION  OF  'GATE$KEEPER '  HAS 
NOT  CHANGED.  THE  ABSOLUTE  ADDRESS  OF  THIS 
PROCEDURE  HAS  3fiEN  SUPPLIED  TO  THE  GATE$MCDULE 
IN  FILE:  GATE. SRC.  IF  IT  HAS  CHANGED  THE  NEW 
ADDRESS  SHOULD  BE  UPDATED  IN  FILE:  GATE. SRC 
AND  RECOMPILED.  ALL  USER  PROCESSES  WILL  HAVE 
TO  BE  RELINKED  WITH  FILE:  GATE. OBJ  AND 
RELOCATED. 


LITERAL  DECLARATIONS  GIVEN  AT  THE  BEGINNING 
OF  SEVERAL  MODULES  ARE  LOCAL  TO  THE  ENTIRE 
MODULE.  HOWEVER,  SOME  ARE  LISTED  THE  SAME 
IN  MORE  THAN  ONE  MODULE.  THE  VALUE  AND 
THEREFORE  THE  MEANING  OF  THE  LITERAL  IS 
COMMUNICATED  ACROSS  MODULE  BOUNDARIES. 
'NOT$FGUND '  USED  IN  LOCATE$EVC  AND 
CREATE$EVC  IS  AN  EXAMPLE.  TO  CHANGE  IT  IN 
ONE  MODULE  AND  NOT  THE  OTHER  WOULD  KILL 
THE  CREATION  OF  ANT  NEW  EVENTCOUNTS  BY  THE 
OS. 


'  */ 


/£0073**************^ *************************************/ 


L2$M0DULE:  DO. 


/ft********************#*******#****************************/ 
/**#******************#»*********************##************  / 
/*  LOCAL  DECLARATIONS  V 


DECLARE 


MAXSCPU 

LITERALLY 

'10  . 

MAX$7PS$CPU 

LITERALLY 

'10'. 

MAX$CPU$$$SMAX$VPS$CPU 

LITERALLY 

'100', 

FALSE 

LITERALLY 

'0'. 

READY 

LITERALLY 

'1', 

RUNNING 

LITERALLY 

'3', 

WAITING 

LITERALLY 

TRUE 

LITERALLY 

'119', 

NOTSFOUND 

LITERALLY 

'255', 

PORTACC 

LITERALLY  ' 

00CCH' , 

RESET 

LITERALLY 

'0'. 

INT$RETURN 

LITERALLY 

'77H'; 

/*GQQ6******************************#**********************/ 

/* 

PROCESSOR  DATA  SEGMENT 

TABLE 

*/ 

/* 

DELARED  PUBLIC 

IN 

MODULE  ' LI $ MODULE' 

V 

/♦ 

IN 

FILE  'LEVEL1 

* 

*/ 

DECLARE  PRDS  STRUCTURE 
(CPU$NUMB5R 

BYTE, 

VP$START 

BYTE, 

VPSEND 

BYTE, 

VPS$PER$CPU 

BYTE. 

WORD) 

COUNTER 

external; 


/*eieQ*****************************************************/ 

/*  GLOBAL  DATA  BASE  DECLARATIONS  */ 
/*  DECLARED  PUBLIC  IN  FILE  'GLOBAL. SRC'  */ 
/*  IN  MODULE' GLOB AL$ MODULE'  */ 
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DECLARE  V?M(  MAX$CPU$$$$MAX$VPS$CPU  )  STRUCTURE 
(7P$ID  BYTE, 

STATE  BYTE. 

VP APRIORITY  BYTE. 

EVC$THRIAD  BYTE, 


EVC$AW$VALUE 

WORD. 

SS$REG 

WORD) 

EXTERNAL? 

DECLARE 

EVENTS 

BYTE 

EXTERNAL? 

DECLARE  EVC$TBL  (100)  STRUCTURE 

(EVCSNAME 

BYTE. 

VALUE 

WORD, 

THREAD 

BYTE) 

EXTERNAL? 

DECLARE 

SEQUENCERS 

BYTE 

EXTERNAL? 

DECLARE  SEO STABLE  (100) 

STRUC TURE 

( SEQ$NAME 

BYTE, 

SEQ$VALUS 

WORD) 

EXTERNAL? 

DECLARE 

NRSVPS (  MAX$CPU  ) 

BYTE 

EXTERNAL, 

NR$RPS 

BYTE 

EXTERNAL, 

HDW$INT$FLAG  (MAX$CPU 

)BYTE 

EXTERNAL. 

GLOBALSLOCX 

BYTE 

EXTERNAL? 

/*0166*** ** *************** *: ************* ** **** *** ******** * */ 
/*  DECLARATION  OE  EXTERNAL  PROCEDURE  REEERENCES  */ 

/*  DECLARED  PUBLIC  IN  FILE  'LEVEL1 . SRC '  */ 

/*  IN  MODULE  'LEVELl$MODULE'  */ 

VPSCHEDULER:  PROCEDURE  EXTERNAL;  END* 

/*  IN  FILE  'SCHED .ASM '  */ 

RETSVP  :  PROCEDURE  BYTE  EXTERNAL?  END? 

LOCATESEVC  ;  PROCEDURE  (EVENT$NAME)  BYTE  EXTERNAL? 

DECURE  EVENT$NAME  BYTE? 

END? 

LOCATE$SEO  :  PROCEDURE  ( SEQ$N AME )  BYTE  EXTERNAL? 

DECLARE  SEO$NAME  BYTE? 


/* 020 5** ************ ****** ****** ******* ******************** / 
/*  DIAGNOSTIC  MESSAGES  (WILL  EVENTUALLY  BE  REMOVED)  */ 

DECLARE 

MSG16(*)  BYTE  INITIAL ( 'ENTERI NG  PREEMT',13,10, '%' ) , 

MSG17 (*)  BYTE  INITIAL ( 'ISSUING  INTERRUPT! ! ',13,10, '%') , 
MSG18( * )  BYTE  INITIAL ( 'ENTERI NG  AWAIT ' ,10 ,13 , '% ' ) , 
MSG19(*)  BYTE  INITIAL( 'ENTERING  ADVANCE  '.10,13,'%'), 
MSG21 (*)  BYTE  INITIAL( 'ENTERING  CREATE$EVC  POR  %'  ) , 

MS G23 ( * )  BYTE  INITIAL! 'ENTERI NG  READ  FOR  EVC:  $'), 
MSG24(*)  BYTE  INITI AL ( 'ENTERING  TICKET', 13, 10, '%') , 

MSG25 (*)  BYTE  INITI AL ( 'ENTERI NG  CREATE$SEQ  %'), 

MSG26 ( * )  BYTE  INITI AL ( 'ENTERI NG  CREATE$PROC ' ,10 ,13 , '% ' ) , 
MS G27 ( * )  BYTE  INITI AL ( 10 , 'ENTERING  GATESKEEPER  N*  %'); 

DECLARE 

CR  LITERALLY  '0DH' , 

LP  LITERALLY  '0AH'J 

/********#*****************************#*******»**»*******/ 


/*0231************************** ***************************/ 

/I******************#**************************************/ 

/**  GATB$KEBPER  PROCEDURE  KLINEP  5-18-62  ****/ 

/*«**********************»*********************#*#******«**/ 


/*  THIS  PROCEDURE  IS  THE  ENTRY  INTO  THE  OPERATING  */ 
/*  SYSTEM  DOMAIN  PROM  THE  USER  DOMAIN.  THIS  IS  THE  */ 
/*  ACCESS  POINT  TO  THE  UTILITY/SERVICE  ROUTINES  AVAIL-  */ 
/*  ABLE  TO  THE  USER.  THIS  PROCEDURE  IS  CALLED  BY  THE  */ 
/*  GATE  MODULE  WHICH  IS  LINKED  WITH  THE  USER  PROGRAM.  */ 
/*  IT  IS  THE  GATE  MODULE  WHICH  PROVIDES  TRANSLATION  */ 
/*  PROM  THE  USER  DESIRED  FUNCTION  TO  THE  FORMAT  RSOUIR-  */ 
/*  ED  FOR  THE  GATEKEEPER.  THE  GATEKEEPER  CALLS  THE  */ 
/*  DESIRED  UTILITY/SERVICE  PROCEDURE  IN  LEVFL2  OF  THE  */ 
/*  OPERATING  SYSTEM  AGAIN  PERFORMING  THE  NECESSARY  */ 
/*  TRANSLATION  POR  A  PROPER  CALL.  THE  TRANSLATIONS  ARE  */ 
/*  INVISIBLE  TO  THE  USER.  THE  GATEKEEPER  ADDRESS  IS  */ 
/*  PROVIDED  TO  THE  GATE  MODULE  TO  BE  USED  FOR  THE  IN-  */ 
/*  DIRECT  CALL.  */ 


/*  */ 
/*  THE  PARAMETER  LIST  IS  PROVIDED  FOR  CONVENIENCE  AND  */ 
/*  REPRESENTS  NO  FIXED  MEANING,  EXCEPT  FOR  'N'.  */ 

/*  N  FUNCTION  CODE  PROVIDED  BY  GATE  */ 

/*  BYT  BYTE  VARIABLE  FOR  TRANSLATION  */ 

/*  »ORDS  WORD  *’  "  *’  */ 

/*  PTR  POINTER  VARIABLE  FOR  TRANSLATION  */ 


/*0278** ***************************************************/ 

GATE$KEEPER :  PROCEDURE (N ,  BYT,  WORDS,  PTR)  REENTRANT  PUBLIC? 

DECLARE 

(N,  BYT)  BYTE, 

WORDS  WORD, 

PTR  POINTER? 


/*  1-0  SERVICES  ARE  NOT  ACKNOWLEDGED  FOR  TWO  REASONS:  */ 
/*  1.  THEY  ARE  CALLED  SO  OFTEN  TEAT  DIAGNOSTIC  OUTPUT  */ 
/*  WOULD  BE  TOO  CLUTTERED.  */ 
/*  2.  THEY  THEMSELVES  PRODUCES  1-0  EFFECTS  THAT  */ 
/*  ACKNOWLEDGE  THEY  ARE  BEING  CALLED.  */ 


IF  N  <  8  THEN  DO? 

CALL  OUT$LINE(0MSG27)? 
CALL  OUT$NUM(N ) ? 

CALL  OUT$CHAR( CR ) ? 

CALL  OUT$CHAR(LF) ? 


END? 


DO  CASE 

N? 

/* 

N 

*/ 

CALL 

AWAIT(BYT, WORDS)? 

/* 

0 

*/ 

CALL 

ADVANCE(BYT)? 

/* 

1 

*/ 

CALL 

CREATEAEVC(BYT); 

/* 

2 

*/ 

CALL 

CREATE$SEO(BYT) ? 

/* 

3 

*/ 

CALL 

TICKET (BYT, PTR ) ? 

/* 

4 

*/ 

CALL 

READ(BYT,PTR) ? 

/* 

5 

V 

CALL 

CREATE$PROC ( PTR ) ? 

/* 

6 

*/ 

CALL 

PREEMPT (  BYT  )? 

/* 

7 

*/ 

CALL 

OUT$CHAR(BYT); 

/* 

8 

*/ 

CALL 

OUT$LINE( PTR ) ? 

/* 

9 

*/ 

CALL 

CUT$NOM( BYT ) ? 

/* 

10 

*/ 

CALL 

OUT$DNUM ( WORDS ) ? 

r* 

11 

*/ 

CALL 

IN$CHAR(PTR ) ? 

/* 

12 

*/ 

CALL 

IN$NUM(PTR) ? 

/♦ 

13 

*/ 

CALL 

IN$DNUM (PTR ) ? 

/* 

14 

V 

END?  /*  CASE  */ 
RETURN? 

END?  /*  GATE$KEEPER  */ 
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/*0 337 ***************************************** ************  / 
/*  CREATE$SVC  PROCEDURE  KLINE?  5-18-82  */ 

/*  CREATES  EVENTCOUNT  FOR  INTER-PROCESS  SYNCHRONIZATION .  */ 

/*  EVENTCOUNT  IS  INITIALIZED  TO  0  IN  THE  EVENTCOUNT  TABLE.*/ 

/t****************************!******#**********************/ 


CREATE$EVC :  PROCEDURE{ NAME )  REENTRANT  PUBLIC; 

DECLARE  NAME  BYTE; 

CALL  OUT$LINE(0MSG21)  J 
CALL  OUT$NUM( NAME ) • 

CALL  OUTSCHAR(CR) * 

CALL  OUT$CHAR(L?) 5 

/*  ASSERT  GLOBAL  LOCK  */ 

DO  WHILE  L0CKSET{3GL03AL$L0CK  ,119) *  END? 

I?  /*  THE  EVENTCOUNT  DOES  NOT  ALREADY  EXIST  */ 
LOCATSSEVC ( NAME)  =  NOT$ FOUND  THEN  DO; 

/*  CREATE  THE  EVENTCOUNT  ENTRY  BY  ADDING  THE  */ 
/*  NEW  EVENTCOUNT  TO  THE  END  OF  THE  EVC$TAPLE  */ 
EVC$TBL( EVENTS ) . EVC$NAME  =  NAME? 

EVC$TBL( EVENTS ) .VALUE  =  0? 

EVC$TBL ( EVENTS ). THREAD  =  255 J 
/*  INCREMENT  THE  SIZE  OF  THE  BVC$TABL3  */ 

EVENTS  =  EVENTS  +  15 
END?  /*  CREATE  THE  EVENTCOUNT  */ 

/*  RELEASE  THE  GLOBAL  LOCK  */ 

GL03AL$L0CK  =  0; 

return; 

end;  /*  CRSATESEVC  procedure  */ 
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/* £403***************************************************** / 
/*  5 SAD  PROCEDURE  ELI  SEP  5-19-82  */ 


/* - v 

/*  THIS  PROCEDURE  ALLOWS  USERS  TO  READ  THE  PRESENT  VALUE  */ 
/*  OF  THE  SPECIFIED  EVSNTSCOUNT  WITHOUT  MAKING  ANT  */ 
/*  CHANGES.  A  POINTER  IS  PASSED  TO  PROVIDE  A  BASS  TO  A  */ 
/*  VARIABLE  IN  THE  CALLING  ROUTINE  FOR  PASSING  THE  RETURN  */ 
/*  VALUE  BACK  TO  THE  CALLING  ROUTINE.  */ 


READ:  PROCEDURS(  EVC$NAME,  RETS $PTR  )  REENTRANT  PUBLIC; 


DECLARE 

EVC$NAME 
EVCTBL$I NDEX 
RETS$PTR 
EVC$VALUE$RET 


BYTE, 

BYTE, 

POINTER, 

BASED  RETS $?TR  WORD 


/*  SET  THE  GLOBAL  LOCK  «*/ 

DO  WHILE  LOCKS ET(0GLOBAL$LOCK ,119) i  END; 

CALL  OUT$LINEOMSG23)  ,* 

CALL  OUT $NUM(EVC$ NAME ) i 
CALL  OUTSCHAR(CR) J 
CALL  OUT$CHAR(LF)? 

/*  OBTAIN  INDEX  */ 

EVCTBLS INDEX  =  LOCATE$EVC{  EVC$NAME  ); 

A  OBTAIN  VALUE  */ 

EVC$VALUE$RET  =  EVC$TBL(  EVCTBL$INDEX  ) .VALUE; 

/*  UNLOCK  GLOBAL  LOCK  */ 

GLOBAL$LOCK  =  0  J 

return; 

end;  /*  READ  PROCEDURE  */ 
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/*0469*****************************************************  / 
/*  AWAIT  PROCEDURE  */ 


/* - */ 

/*  INTER  PROCESS  SYNCHRONIZATION  PRIMITIVE.  SUSPENDS  */ 
/*  EXECUTION  OF  RUNNING  PROCESS  UNTIL  THE  EVENTCOUNT  HAS  */ 
/*  REACHED  THE  SPECIFIED  THRESHOLD  VALUE,  "AWAITEDAVALUS .  "*/ 
/*  USED  BT  THE  OPERATING  SYSTEM  FOR  THE  MANAGEMENT  OF  */ 
/*  SYSTEM  RESOURCES.  */ 


AWAIT:  PROCEDURE ( EVC AI D , AWAITED A VALUE )  REENTRANT  PUBLIC J 
DECLARE 

AWAITED$VALUE  WORD, 

(EVC AID,  NEEDASCHED,  RUNNINGAVP, EVCTBLA INDEX )  3YTEJ 
CALL  0UTALINEOMSG18); 

/*  LOCK  GLOBAL  LOCK  */ 

DO  WHILE  LOCK ASET (GGLOBALA LOCK,  119);  END? 

NESDASCRED  =  TRUE; 

/*  DETERMINE  THE  RUNNING  VIRTUAL  PROCESSOR  */ 

RUNNINGAVP  *  RETAVPJ 

/*  GET  EVC  INDEX  */ 

EVCT3LAINDEX  =  LOCATE ABVC( EVC AID ) ? 

/*  DETERMINE  IF  CURRENT  VALUE  IS  LESS  THAN  THE 
AWAITED  VALUE  */ 

IF  EV C AT BL( EVCTBLA INDEX ) .VALUE  <  AWAITEDA VALUE  THEN  DO; 

/*  BLOCK  PROCESS  */ 

V?M( RUNNINGAVP ) . ST  ATE  =  WAITING; 

VPM(RUNNlNGAVP).EVCATHREAD=EVCATBLiEVCTBLAlNDEX) .THREAD 
VPM( RUNNINGAVP ) . EVCAAWA VALUE  =  AWAITEDAVALUEJ 
EVC ATBL (  EVCTBLAI NDEX  ). THREAD  =  RUNNINGAVP; 

END?  /*  BLOCK  PROCESS  */ 

ELSE  /*  DO  NOT  BLOCK  PROCESS  */ 

NEEDASCHED  *  FALSE; 

/*  SCHEDULE  THE  VIRTUAL  PROCESSOR  */ 

IF  NEEDASCHED  =  TRUE  THEN 

CALL  VPSCHEDULER!  /*  NO  RETURN  */ 

/*  UNLOCK  GLOBAL  LOCK  */ 

GLOBALALOCK  =  0; 
return; 

END?  /*  AWAIT  PROCEDURE  */ 
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/♦0  53  5**  *****♦**♦♦♦♦**  / 

/*  ADVANCE  PROCEDURE  KLI NEF  5-19-62  */ 


/* - */ 

/*  INTER  PROCESS  SYNCHRONIZATION  PRIMITIVE.  INDICATES  */ 

/*  SPECIFIED  EVENT  HAS  OCCURED  EY  ADVANCING! INCREMENTING ) */ 
/*  THE  ASSOCIATED  EVENTCOUNT.  EVENT  IS  BROADCAST  TO  ALL  */ 
/*  VIRTUAL  PROCESSORS  AWAITING  THAT  EVENT.  */ 

/*  CALLS  MADE  TO:  0UT$LINE  */ 

/*  VPSCHEDULEP  (NO  RETURN)  V 


/**##*#*#**«**###******* ****** $***#***##** 9***#$**#**#****^  / 


ADVANCE:  PROCEDURE ( EVC $1 D )  REENTRANT  PUBLIC? 


DECLARE 

(EVC$ID,  NEEDSSCHED,  NEED$I  NT?. ,  EVCTBL$  INDEX)  BYTE, 

(SAVE,  RUNNING$VP,  I,  CPU)  3YTE? 

CALL  0UT$LINE(0MSG19)  ? 

/♦  LOCK  THE  GLOBAL  LOCK  */ 

DO  WHILE  LOCKSET( OGLOBAL^LOCK ,1 19 ) *  END  » 

RUNNINGS  VP  =  RET$VP? 

EV  CTBL$I NDEX  =  LOCATE$EVC( EVCSID) ? 

EVC$TBL( EVCTBL$ INDEX ) . VALUE=E VC $TBL(EVCTBL$ INDEX) .VALUE  +  1? 
NESD$SCHED  =  FALSE? 

NEED$I NTR  =  FALSE? 

SAVE  =  255? 

I  =  EVCSTBL (  EVCTBLSINDEX  ). THREAD? 

DO  WHILE  I  <>  255? 

IF  VPM( I ) .EVC$AW$VALUE  <  =  EVC$TBL ( EVCT3L$ I NDEX ) . VALUE 
THEN  DO?  /*  AWAKEN  THE  PROCESS  */ 

VPM(I) .STATE  =  READY? 

V?M(I).EVC$AW$VALUF  =  0? 

CPU  *  I  /  MAXSVPS $CPU  ? 

IF  SAVE  »  225  THEN  DO?  /♦THIS  FIRST  ONE  IN  LIST* 
EVC$T3L(EVCT3L$ INDEX ) . THRSAD=VPM { I ) .EVCST3R* AD : 

VPM(  I  ) .EVCSTHREAD  =  255? 

I  =  EVC$TBL (  SV  CT  BLS INDEX  ). THREAD? 

END?  /*  IF  FIRST  */ 

ELSE  DO?  /*  THEN  THIS  NOT  FIRST  IN  L ' 5 T  • 

VPM (  SAVE  ).EVC$THREAD  =  V?M>  I  >.  SV  C  t  * 

VPM (  I  ) .EVCSTEREAD  =  255? 

I  =  VPM(  SAVE  ) .EVCS THREAD? 

END?  /*  IF  NOT  FIRST  */ 

IF  (  CPU  <>  PRDS  .CPUSNUM3SR  ?*•”. 

HDW$INT$FLAG (  CPU  )  =  TRUE? 

NEED$INTR  =  TRUE: 

END? 


ELSE  NEED$SCHED  *  TRUE; 

END?  /♦IE  AWAKEN  */ 

ELSE  DO?  /*  DO  NOT  AWAKEN  THIS  PROCESS  */ 

SATE  =  I? 

I  =  TPM(  I  ).EVC$THREAD? 

END?  /*  I?  NOT  AWAKEN  */ 

END?  /*  DO  WHILE  */ 

IF  NEED$INTR  *  TRUE  THEN  DO?  /*  HARDWARE  INTR  */ 
CALL  OUT$LINE(  0MSG17  )? 

DISABLE? 

OUTPUT(PORT$CC )  *  80H? 

CALL  TIME(l)? 

OUTPUT ( PORT $CC)  »  RESET? 

ENABLE? 

END?  /*  NESD$INTR  */ 

IF  NEED$SCHED  *  TRUE  THEN  DO? 

VPM( RUNNINGS VP). ST ATE  =  READY? 

CALL  VPSCHEDULER?  /*  NO  RETURN  ♦/ 

END?  /*  IF  NEEDSSCHED  */ 

/*  UNLOCK  THE  GLOBAL  LOCK  */ 

GLOB AL$ LOCK  »  0? 

RETURN? 

END?  /*  ADVANCE  PROCEDURE  */ 
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/*0667**************** *************************************/ 
/*  PREEMT  PROCEDURE  KLINE?  5-19-82  */ 

/*  THIS  PROCEDURE  AWAKENS  A  HI  PRIOITY  PROCESS  LEAVING  */ 
/*  THE  CURRENT  RUNNING  PROCESS  IN  THE  READY  STATE  AND  */ 
/*  CALLS  FOR  A  RESCHEDULING.  THE  HIGH  PRIORITY  PROCESS  */ 
/*  SHOULD  BLOCK  ITSELF  WHEN  FINISHED.  */ 

/*  IF  THE  ?P$ID  IS  'FI'  OR  THE  MONITOR  PROCESS,  IT  WILL  */ 
/*  make  IT  READY  WHERE-EVER  IT  IS  IN  THE  FPM.  THE  FOLLOW-*/ 
/*  ING  CODE  DOES  NOT  TAKE  ADVANTAGE  OF  THE  FACT  THAT  */ 

/*  CURRENTLY  IT  IS  THE  THIRD  ENTRY  IN  THE  VPM  FOR  EACH  */ 
/*  REAL  PRO CIS OR.  */ 

/* - */ 

/*  CALLS  MADE  TO:  OUTLINE,  VPSCHEDULER  */ 

/**********************************************************/ 
PREEMPT:  PROCEDURE(  7P$ID  )  REENTRANT  PUBLIC,* 


DECLARE  (VP$ID,SEARCH$ST,SEARCH$END, CPU, INDEX)  BYTE; 


CALL  OUT$LINE(  0MSG16  ); 

IF  VP$ID  <>  0FEH  THEN  DOi  /*  NORMAL  PREEMT  */ 

/*  SEARCH  VPM  FOR  INDEX  FOR  ID  */ 

SEARCH$ST  «  0; 

DO  CPU  »  0  TO  <NR$RPS  -  1); 

SEARCH$END  -  SEARCE$ST  +  NR$VPS(  CPU  )  -  1  5 
DO  INDEX  >  SEARCH$ST  TO  SEARCH$END; 

IF  VPM(  INDEX  ).VP$ID  *  VP$ID  THEN  GO  TO  FOUND; 
END?  /*  DO  INDEX  */ 

SEARCH$ST  «  SEARCH$ST  +  MAX$VPS$CPU; 

end;  /*  do  cpu  */ 

/*  CASE  IF  NOT  FOUND  IS  NOT  ACCOUNTED  FOil  CURRENTLY  */ 
FOUND: 

/*  LOCK  TEE  GLOBAL  LOCK  */ 

DO  WHILE  L0CK$SET(9GL0BAL$L0CK ,119) 5  END; 

/*  SET  PREEMPTED  VP  TO  READY  */ 

VPM(  INDEX  ). STATE  »  READY; 

/*  NEED  HARDWARE  INTR  OR  RE-SCHBD  */ 

IF  (  CPU  »  PRDS.CPU* NUMBER  )  THEN  DO? 

INDEX  *  RET$VP;  /*  DETERMINE  RUNNING  PROCESS  */ 
VPM(  INDEX  ). STATE  *  READY?  /*  SET  TO  READY  */ 
CALL  VPSCHEDULER?  /*  NO  RETURN  */ 

END? 

ELSE  DO;  /*  CAUSE  HARDWARE  INTERRUPT  */ 

CALL  0UT$LINEOMSG17); 

HDW$INT$FLAG (  CPU  )  *  TRUE; 

disable;  output(  port$cc  )  »  80s; 

CALL  TIME(l); 

OUTPUT (  PORT5CC  )  *  RESET;  ENABLE? 

end; 

END?  /*  NORMAL  PREEMT  */ 
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ELSE  DO;  /*  PREEMT  THE  MONITOR  */ 

/*  SEARCH  7PM  POR  ALL  ID'S  OP  0FEH  */ 
SEARCHAST  *  0  * 

DO  WHILE  LOCKASET( 0GLOB ALALOCX, 119) ?  END? 

DO  CPO  »  0  TO  (NR ARPS  -  1); 

SEARCH$END  -  SEARCH$ST  ♦  NR$VPS(  CPD  )  - 
/*  SET  ALL  IN T A FLAGS  EXCEPT  THIS  CPU'S  */ 
IF  PRDS . CPO AN0MBER  <>  CPU  TEEN 
HDVAINTAFLAG(  CPU  )  »  TRUE? 

DO  INDEX  -  SEARCHAST  TO  SEARCHAEND; 

IF*  7PM (  INDEX  )  .7PAID  «  7PAID  THEN 
7PM(  INDEX  ). STATE  *  READY? 

END?  /*  DO  */ 

SEARCHAST  *  SEARCHAST  ♦  MAX$7PS$CPU? 

END?  /♦  ALL  MONITOR  PROCESS  SET  TO  READY  */ 
/*  INTERRUPT  THE  OTHER  CPU'S  AND 
RESCHEDULE  THIS  ONE  */ 

CALL  OUT$LINE(0MSG17); 

DISABLE? 

OUTPUT (  PORTACC  )  «  80H? 

CALL  TIME(1)J 

OUTPUT (  PORTACC  )  =  RESET? 

enable; 

INDEX  *  RETA7PJ 

7PM (INDEX). ST ATE  =  READY? 

CALL  YPSCHEDULER?  /*  NO  RETURN  */ 

END;  /*  ELSE 

/*  UNLOCI  GLOBAL  MEMORY  */ 

GLOBALALOCK  »  0? 

return; 

D?  /*  PREEMPT  PROCEDURE  */ 


/*0?99**************^**  ***********************************/ 

/*  C?.EATE$SEQ  PROCEDURE  EL  I  NEE  5-20-82  */ 

/*  CREATOR  OF  INTER  PROCESS  SEQUENCER  PRIMITIVES  FOR  USER  */ 
/*  PROGRAMS.  CREATES  A  SPECIFIED  SEQUENCER  AND  INITIAL-  •/ 
/*  12 ES  IT  TO  0,  BT  ADDING  THE  SEQUENCER  TO  THE  END  OF  THE*/ 
/*  SEQUENCER  TABLE.  */ 

/*  CALLS  MADE  TOs  OUT$LINE  OUT$CHAR  */ 

/*  OUT$HEX  */ 

CREATESSEQ:  PROCEDURE( NAME )  REENTRANT  PUBLIC! 

DECURE  NAME  BITE! 


/♦  ASSERT  GLOBAL  LOCI  */ 

DO  WHILE  LOCKSBT (0GLOBAL$LOCK ,119) *  END! 

CALL  0UT$LINE(GMSG25) ; 

CALL  OUT $HEX( NAME); 

CALL  OUT$CHAR(CR); 

CALL  OUT$CHAR(LF); 

IF  /*  THE  SEQUENCER  DOES  NOT  ALREADY  EXIST,  IE  */ 
LOCATE$SEQ(NAME)  *  NOT$ FOUND  THEN  DO; 

/♦  CREATE  THE  SEQUENCER  ENTRY  BY  ADDING  THE  */ 
/*  NEW  SEQUENCER  TO  THE  END  OF  THE  SEQ$TA3LE  */ 
SEQ$TABLE(SEQUENCERS).SEQ$NAME  =  NAME; 

SEQ$T ABLE (SEQUENCERS ) .SEQ$ VALUE  *  0! 

/*  INCREMENT  NUMBER  OF  SEQUENCERS  */ 
SEQUENCERS  *  SEQUENCERS  +  l; 

END?  /*  CREATE  THE  SEQUENCER  */ 

/*  RELEASE  THE  GLOBAL  LOCI  */ 

GLOBALSLOCE  -  0; 

return; 

end;  /*  create$seq  procedure  */ 


/*086 5** ***************************************************/ 
/*  TICKET  PROCEDURE  KLINE?  5-20-82  */ 


/* - */ 

/*  INTER-VIRTUAL  PROCESSOR  SEQUENCER  RPIMITIVE  ?OR  USER  */ 
/*  PROGRAM.  SIMILAR  TO  "TAKE  A  NUMBER  AND  WAIT."  RETURNS*/ 
/*  PRESENT  VALUE  0?  SPECI?IED  SEQUENCER  AND  INCREMENTS  THE*/ 
/*  SEQUENCER.  A  POINTER  IS  PASSED  TO  PROVIDE  A  BASE  TO  A  */ 
/*  VARIABLE  IN  THE  CALLING  ROUTINE  POR  PASSING  THE  RETURN  */ 


/*  VALUE  BACK  TO  THE  CALLING  ROUTINE.  */ 

/* - */ 

/*  CALLS  MADE  TO:  OUT$LINE  */ 


/**********************************************************/ 

TICKET:  PROCEDURE(  SEO$NAME,  RETS$PTR  )  REENTRANT  PUBLIC? 
DECLARE 

SEQ$NAME  BYTE, 

SEQ.TBL$  INDEX  BYTE, 

RETS$PTR  POINTER, 

SEQ$VALUE$RET  BASED  RETS$PTR  WORD? 

/*  ASSERT  GLOBAL  LOCK  */ 

DO  WHILE  L0CKSET(0GL0BAL$L0CK,119);  END? 

CALL  0UT$LINE{0MSG24) ? 

/*  OBTAIN  SEQ$NAME  INDEX  */ 

SEOTBL$INDEX  -  LOCATE$SEQ(  SEQ$NAME  )? 

/*  OBTAIN  SEQUENCER  VALUE  */ 

SEQ$VALUE$RET  *  SEQ$TABLE(  SEQTBL$INDEX  ).SEQ$VALUE? 

/*  INCREMENT  SEQUENCER  */ 

SEQ$TABLE(  SEQTBL$I NDEX  )  ,SEQ$VALUE  = 

SEQ$TABLE(SEQTBL$INDEX) ,SEQ$VALUE  +  1  ? 

/*  UNLOCK  THE  GLOBAL  LOCK  */ 

GLOBAL$LOCK  *  0  ? 

RETURN? 

END?  /*  TICKET  PROCEDURE  */ 
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/*0931******************** ****** ***************************/ 


/*  CRE*TE$PROC  PROCEDURE  XLINEF  5-20-82  */ 

/* - - */ 

/*  THIS  PROCEDURE  CREATES  A  PROCESS  FOR  THE  USER  AS  */ 

/*  SPECIFIED  3T  THE  INPUT  PARAMETERS  CONTAINED  IN  A  */ 

/*  STRUCTURE  IN  THE  CATE  MODULE.  THE  PARAMETER  PASSED  */ 

/*  IS  A  POINTER  WHICH  POINTS  TO  THIS  STRUCTURE.  */ 

/*  INFO  CONTAINED  IN  THIS  STRUCTURE  IS:  PROCESS  ID.  */ 

/*  PROCESS  PRIORITY ,  THE  DESIRED  PROC  STACK  LOCATION,  */ 

/*  AND  THE  PROCESS  CODE  STARTING  LOCATION  WHICH  IS  */ 

/*  IS  TWO  ELEMENTS:  THE  IP  REGISTER  (OFFSET)  AND  THE  */ 

/*  CS  REGISTER  (CODE  SEGMENT).  */ 

/*  CALLS  MADE  TO:  OUTLINE  */ 


/»****« *♦****##***********#****#*#***##**##****#***********/ 

CREATE$PROC:  PROCEDURE (  PROC$PTR  )  REENTRANT  PUBLIC? 

DECLARE 

PROC5PTB  POINTER, 

PROC$TABLE  BASED  PROC$PTR  STRUCTURE 
( PROC $ ID  BITE, 

PROC $ PR I  BITE, 

PROC$STACK$SEG  WORD, 

PROC$IP  WORD, 

PROC5CS  WORD)? 

DECLARE 

(PS1,  PS2)  WORD, 

TEMP  BITE? 


DECURE  PROC$STACK$PTR  POINTER  AT(OPSl), 

PROC$STACK  BASED  PROC$STACK$PTR  STRUCTURE 


(SP  WORD, 

BP  WORD, 

RET$TYPE  WORD, 

LENGTH (0FEH)  BYTE. 

DI  WORD, 

SI  WORD, 

DS  WORD, 

DX  WORD, 

CX  WORD, 

AX  WORD, 

BX  WORD, 

ES  WORD, 

IP  WORD, 

CS  WORD, 

FL  WORD)? 


CALL  0UT$LINE(0MSG26) ? 
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/*  TO  SET  UP  PROC$STACK$PTR  */ 

PS1  *  0; 

PS 2  =  PROC$TABLE.PROC$STACK$SEG; 

PROC$STACK.SP  -  104HJ 

PROC$STACI.BP  »  0 » 

PROC$STACK.RET$TYPE  =  INT$RETURNJ 
PROC$STACK .DI  =  0; 

PROCSSTACI.SI  =  0; 

PROC5STACK.DS  *  0? 

PROC$STACK.DX  »  0.* 

PROC$STACK.CX  =  0i 

PROC$STACK. AX  »  01 

PROC$STACX .BX  =  0f 

PROC$STACX.ES  =  0J 

PROC$STACK.IP  *  PROC$ TABLE . PROC$IP* 

PROC$STACK.CS  «  PROC$TABLE.PROC$CS; 

PROC$STACK.FL  »  200HJ  /*SET  IF  FLAG  (ENABLE  INTR)*/ 

/*  SET  GLOBAL  LOCK  */ 

DO  WHILE  LOCKSET(0GLOBAL$LOCX ,119);  END; 

IF  PRDS.Y?S$PER$CPU  <  MAX$YPS$CPU  THEN  DO; 

TEMP  *  PRDS . YPS$PER$CPU  ♦  PHDS . VP$START; 

YPM(  TEMP  ).TP$1D  »  PROC$TABLE .PROC$ID* 

VPM(  TEMP  ). STATE  =  01;  /*  READY  */ 

YPM(  TEMP  ).VP$PRIORITY  *  PROCSTABLE .PROCSPRI J 
YPM(  TEMP  ).EYC$ THREAD  *  255? 

YPM(  TEMP  ).EYC$AWmLUB  *  0; 

YPM(  TEMP  ) .SS$REG  *  PROCSTABLE ,PROC$STACK$SSG; 


PRDS.YPS$PER$CPU  »  PRDS ,VPS$PER$CPU  +  1J 
I  PRDS . ?P$END  *  PRDS .YPSEND  ♦  1? 

’  NR$FPS(  PRDS .CPU$N UMBER  )  » 

NR$YPS (PRDS .C?U$NUMSER)  ♦  l; 

END;  /*  DO  */ 


/*  RELEASE  THE  GLOBAL  LOCK  */ 
GLOBALUOCK  -  0? 

return; 

end;  /*  CREATE$PROCESS  */ 
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/* 1063***************************************************** / 

/*  IN$CHAR  PROCEDURE  ELI  NEE  5-22-62  */ 


/*  CITS  A  CHAP  FROM  THE  SERIAL  PORT.  CHAR  IS  ! ! !NOTI ! !  */ 
/*  ECHOED.  THAT  IS  RESPONSIBILTY  OF  USER  IN  THIS  CASE.  V 
/*  INPUT  TO  SERIAL  PORT  VIA  SBC861  DOWN  LOAD  PROGRAM  MAY  */ 
/*  NOT  BE  ACCEPTED.  */ 

/*  POINTER  IS  PROVIDED  BY  USER  SO  EE  CAN  BE  RETURNED  THE  */ 
/*  CHARACTER  .  */ 

/* - */ 

/*  CALLS  MADE  TO:  RECV$CAHR  */ 

Z*****^**************  *******  4^  4^**********«******  *********/ 


IN$CHAR:  PROCEDURE  (  RET$PTR  )  REENTRANT  PUBLIC; 

DECLARE 

RETSPTR  POINTER, 

INCHR  BASED  RET$PTR  BYTE* 

DISABLE; 

inchr  =  recv$char; 

enable; 

return; 

end;  /*  IN$CHAR  */ 

/*1094************** ****************************** *********/ 

/*  IN$NUM  __  PROCEDURE^  __  KLINE?  5-22-82  */ 

/*  GETS  TWO  ASCII  CHAR  FROM  THE  SERIAL  PORT,  EXAMINES  */ 

/*  THEM  TO  SEE  IF  THEY  ARE  IN  THE  SET  0..F  HEX  AND  FORMS  */ 

/*  A  BYTE  VALUE.  BACH  VALID  HEX  DIGIT  IS  ECHOED  TO  THE  */ 
/*  CRT.  IMPROPER  CHAR  ARE  IGNORED.  NO  ALLOWANCES  ARE  */ 

/*  MADE  FOR  WRONG  DIGITS.  GET  IT  RIGHT  THE  FIRST  TIME.  */ 

/*  IF  YOU  ARE  INDIRECTLY  ACCESSING  THE  SERIAL  PORT  VIA  */ 
/*  THE  SBC861  DOWN  LOAD  PROGRAM  FROM  THE  MDS  SYSTEM  */ 

/*  INPUT  MAT  NOT  BE  ACCEPTED.  A  POINTER  IS  PASSED  BY  TEE*/ 
/*  USER  SO  THAT  HI  RETURNED  THE  CHARACTER.  */ 

/* - */ 

/*  CALLS  MADE  TO:  IN$HEX  */ 

/*********4^****************:******************«************  / 

IN $ NUM:  PROCEDURE  (  RET$PTR  )  REENTRANT  PUBLIC; 

DECLARE 

RET$PTR  POINTER, 

NUM  BASED  RET$PTR  BYTE; 

disable; 

NUM  »  IN$HEX; 

enable; 

return; 

end;  /*  IN$NUM  */ 
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/*1129  ******************#*****<«c^#***#*********###*******#*/ 

/t#************^*************************************,',*****^ 

/!—  <WpCHAR_  PROCEDURE  KLINE?  5-20-82  */ 

/♦  SENDS  A  BITE  TO  THE  SERIAL  PORT  */ 


/*• 


♦/ 


/*  CALL  MADE  TO:  SENDSCHAR  */ 

/****^************* ************************  ***  ************/ 

OUTSCHAR:  PROCEDURE*  CHAR  )  REENTRANT  PUBLIC? 

DECLARE  CHAR  BITE? 

DISABLE? 

CALL  SEND$CHAR(  CHAR  ); 

enable; 

return; 

end; 


/M153^************^*************************************/ 


/*  OUTSLINE  PROCEDURE  KLINE?  5-20-e2  */ 

/* — - */ 

/*  USING  A  POINTER  TO  A  BU??ER  IT  WILL  OUTPUT  AN  ENTIRE  */ 
/*  LINE  THRU  THE  SERIAL  PORT  UNTIL  AN  IS  ENCOUNTERED  */ 
/*  OR  80  CHARACTERS  IS  REACHED— WHICH  EVER  IS  ?IRST.  CR'S*/ 
/*  AND  LP'S  CAN  BE  INCLUDED.  */ 

/* - */ 

/*  CALLS  MADE  TO:  SENDS CHAR  */ 


/**********************************************************  / 


OUTSLINE:  PROCEDURE(  LINESPTR  )  REENTRANT  PUBLIC? 
DECLARE 

LINESPTR  POINTER, 

LINE  BASED  LINES PTR  (80)  BITE, 

ii  bite; 
disable; 

DO  II  «  0  TO  79; 

I?  LINE(  II  )  *  '%'  THEN  GO  TO  DONE? 

CALL  SENDSCHAR(  LINK  II  )  )? 

END; 

DONE:  ENABLE; 

return; 

end; 
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/♦1.195**************  ***************************************/ 
/*  OUT$NUM  PROCEDURE  KLINE?  5-20-82  */ 


/*  OUTPUTS  A  SITE  VAULE  NUMBER  THRU  THE  SERIAL  PORT 
/*  CALLS  MADE  TO:  OUT$HEX  */ 

/**^*#*^***#****:M«*>I*  *************************************/ 

OUT$NUM:  PROCEDURE!  NUM  )  REENTRANT  PUBLIC; 

DECLARE  NUM  BYTE? 

disable; 

CALL  OUT$HEX<  NUM  ); 

enable; 

return; 

end; 


/«12i,8**************  ******************************  *********/ 

/*  IN$DNUM  PROCEDURE  KLINE?  5-22-82  */ 


/*  GETS  ?OUR  ASCII  PROM  SERIAL  PORT  TO  ?ORM  WORD  VALUE 
/*  CRITERIA  ARE  THE  SAME  AS  IN  PROCEDURE  IN$NUM. 


/M26 1*****************************************************/ 

/♦  OUT$DNUM  PROCEDURE  ELI  NEE  5-20-82  */ 

/♦  OUTPUTS  A  WORD  VALUE  NUMBER  VIA  THE  SERIAL  PORT  */ 

/*  CALLS  MADE  TO:  OUT$HEX  V 

/if#**********##************##*#*#***#*#****###*#**##******#/ 


OUT$DNUM:  PROCEDURE (  DNUM  )  REENTRANT  PUBLIC; 

DECLARE 

DNUM  WORD, 

SEND  byte; 

disable; 

SEND  *  HIGrH(  DNUM  ); 

CALL  OUT$HEX(  SEND  ); 

SEND  =  LOW (  DNUM  )J 
CALL  OUT$HEX(  SEND  )J 

enable; 

return; 

end; 


l  * 

/^lESd**************^******************************'^******/ 


/♦  RECV$CHAR  PROCEDURE  KLINEF  5-22-82  */ 

/* - */ 

/*  BOTTEM  LEVEL  PROCEDURE  THAT  03TAINS  A  CHAR  FROM  THE  */ 

/*  SERIAL  PORT.  PARITY  BIT  IS  REMOVED.  CHAR  IS  ! ! NOT ! !  */ 
/*  ECHOED.  */ 

/♦  CALT<’  MADE  TO:  NONE  */ 


/*******************************#**************************/ 


RECV$CHAR:  PROCEDURE  BYTE  REENTRANT  PUBLIC; 

DECLARE 

CHR  byte; 

/♦CHECH  PORT  STATUS  BIT  2  FOR  RECEIVE-READY  SIGNAL  */ 
DO  WHILE  (INPUT(0DAH)  AND  02H)  =  0;  END? 

CHR  «  ( INPUT (0D8H )  AND  07FH); 

RETURN  CHR? 

end; 
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/M327***************************************************** / 
/*  S END $ CHAR  PROCEDURE  KLINEF  5-20-82  */ 

/* - */ 

/*  OUTPUTS  A  BITE  THRU  THE  SERIAL  PORT.  THIS  IS  NOT  A  */ 
/*  SERVICE  AVAILABLE  THRU  TEE  GATEKEEPER  BUT  IT  IS  CALLED*/ 
/*  BY  MANY  OP  THOSE  PROCEDURES.  IT  WILL  STOP  SENDING  */ 
/*  (AND  EVERYTHING  ELSE)  IF  IT  SEES  A  ~S  AT  INPUT.  ~Q  V 
/*  WILL  RELEASE  THE  PROCEDURE  TO  CONTINUE.  */ 

/*  THE  USER  BEWARE! II!!  THIS  IS  ONLY  A  DIAGNOSTIC  TOOL  */ 
/*  TO  FREEZE  THE  CRT  FOR  STUDY.  RELEASING  IT  DOESN'T  */ 
/*  ASSURE  NORMAL  RESUMPTION  OF  EXECUTION.  (YOU  MAY  FORCE*/ 


/*  ALL  BOARDS  TO  IDLE  FOR  EXAMPLE.)  */ 

/*  CALLS  MADE  TO:  */ 


/ft*****##*##*******#****#**********#**************#********/ 

SBND$CHAR:  PROCEDURE (CHAR )  REENTRANT  PUBLIC? 

DECLARE  (CHAR, INCHR )  BYTE? 

/*  CHECK  PORT  STATUS  */ 

INCHR  =  ( INPUT (0D8H)  AND  07FH)? 

IF  INCHR  =  13H  THEN 

DO  WHILE  (INCHR  <>  11H)? 

IF  (( INPUT (0D AH)  AND  02H)  <>  0)  THEN 
INCHR  =  (INPUT(0D8H)  AND  07FH)? 

END? 

DO  WHILE  (INPUT(0DAH)  AND  01H)  *  0?  END? 

OUTPUT (0D8H)  =  CHAR? 

return; 

end; 
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/*1393***************************************************** / 
/*  IN$HEX  PROCEDURE  KLINSF  5-22-82  */ 

/*  SETS  2  HEX  CHAR  FROM  THE  SERIAL  PORT  AND  IGNORES  ANT-  */ 

/*  THING  ELSE.  EACH  VALID  HEX  DIGIT  IS  ECHOED  TO  THE  */ 

/*  SERIAL  PORT.  A  BYTE  VALUE  IS  FORMED  FROM  THE  TWO  HEX  */ 

/*  CHAR.  */ 

/*  CALLS  MADE  TO:  RECV$CHAR  */ 


/**********4******************** ft#*************************/ 


IN$HEX:  PROCEDURE  BYTE  REENTRANT  PUBLIC? 


DECLARE 

ASCII!*)  BYTE  DATA  ( '0123456789ABCDEF ' ) . 

AS C 1 1 L ( * )  BYTE  DATA! '0123456789 '  ,61H,623,63H,64H,65H, 
66H ) , 

(INCHR,  HEXNUM,  H,  L)  BYTE, 

FOUND  BYTE, 

STOP  BYTE? 


/*  GET  HIGH  PART  OF  BYTE  */ 

FOUND  =  0? 

DO  WHILE  NOT  FOUND? 

/*  IF  INVALID  CHAR  IS  INPUT,  COME  BACK  HERE  */ 
INCHR  =  REC V$CHAR? 

H  =  0? 

STOP  =  0? 


I 
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/*  COMPARE  CHAR  TO  HEX  CHAR  SET  */ 

DO  WHILE  NOT  STOP* 

I?  (INCHR-ASCIHH) )  OP.  (INCUR  *  ASCIIL(H))  THEN  DO 
STOP  »  0FFEJ 
POUND  *  0FFH* 

CALL  SEND$CHAR(  INCH?  )»  /*  TO  ECHO  IT  V 

end; 

ELSE  do; 
h  =  H  +  1; 

IP  H  -  10H  THEN  STOP  =  0FPH; 

END;  /*  ELSE  v 
END;  /*  DO  WHILE  */ 

H  *  SHL(  H,  4  ),* 

END;  /*  DO  WHILE  V 
POUND  *  0; 

/*  SET  LOW  PART  OP  BYTE  */ 

DO  WHILE  NOT  POUND* 

/*  ASAIN  DO  UNTIL  VALID  HEX  CHAR  IS  INPUT  V 
INCHR  *  RECV$CHAR; 

l  *  0h; 
stop  =  e; 

do  while  not  stop; 

IF  ( INCHR=ASCII  (L) )  OR  (lNCHR=ASCIILa) )  THEN  DO; 

stop  »  0pph; 

FOUND  *  0PFH  J 

CALL  SEND$CHAR(INCHR )? 

end; 
else  do; 

L  *  L  +  1; 

IF  L  *  10H  THEN  STOP  *  0FFH; 

END;  /*  ELSE  */ 

END;  /*  DO  WHILE  */ 

END;  /*  DO  WHILE  */ 

RETURN  (H  OR  L); 

END;  /*  IN$HEX  ♦/ 
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/*1 *2  z**#**#**#****##*#*#*#*#***********#***#************** / 
/*  OUT$HEX  PROCEDURE  KLINE?  5-20-82  */ 


/* 


— */ 


/*  TRANSLATES  BITE  VALUES  TO  ASCII  CHARACTERS  AND  OUTPUTS*/ 
/*  THEM  THRU  THE  SERIAL  PORT  */ 

/*  CALLS  MADE  TO:  SEND$CHAF.  */ 

/ft#********#*##******# ******************** ##*****##*****##* / 

OUT$HEX:  PROCEDURE(B)  REENTRANT  PUBLIC; 


DECLARE  B  BITE? 

DECLARE  ASCII (*)  BYTE  DATA  ( '0123456789A3CDEF ') ? 

CALL  SEND$CHAR( ASCI  I (SHR(B ,4 )  AND  0?H))» 

CALL  SEND$CHAR ( ASCI I (B  AND  0FH) ) * 

return; 

end; 

/t**^****^*********^*******************#********  **##***/ 

end;  /*  L2$M0DULE  */ 


/************************************♦*******************/ 
/*******************************#**************#****«****/ 
/ * ****************** ************ ********** ***************/ 


- 


no 


All  of  the  source  code  tr  LEVEL  I,  except  the  scheduler 
and  interrupt  handler,  is  contained  in  file:  LEVEL1.SRC. 
It  is  compiled  with  the  LARGE  attribute.  The  two  exceptions 
are  written  in  ASM86  and  had  to  be  listed  in  their  own 
module.  LEVEL  I  is  one  of  the  relocatable  code  modules  in 
file:  KORE.LNK.  It  is  part  of  the  executable  code  module 
in  file:  KORE.  This  module  contains  utility  procedures 
used  only  by  the  operating  system.  The  memory  map  for  all 
of  KORE  is  located  at  the  end  of  this  Appendix.  The  map 
comes  from  file:  K0RE.MP2. 


/********************* #**#******«*****************»«#******/ 
/ft***!!^****#**#*#***#*#**#*#*#*#******#*****###***#*****###/ 

/**  *******************  *******  ***  ***************************/ 

/*  FILE:  LEVEL1.3RC 

VERSION:  KLINEF  5-25-82 

PROCEDURES 

DEFINED:  RETSVP  RDYTHISVP 

GETWORK  LOCATESEVC 

LOCATE$SEO  IDLE$PROC 
MONITOR$PROC 

REMARKS : 

WARNING:  SEVERAL  OF  THE  LITERAL  DECLARATIONS  BELOW 
HAVE  A  SIMILAR  MEANING  IN  OTHER  MODULES.  THAT  MEAN¬ 
ING  IS  COMMUNICATED  ACROSS  MODULES  BOUNDARIES.  BE 
CAREFUL  WHEN  CHANGING  THEM. 

*/ 

/**********************************************************/ 
Ll$MODULE:  do; 

/*QQ2±*****************************************************/ 
/**********************************************************/ 
/+  LOCAL  DECLARATIONS  */ 

DECLARE 


MAX$CPU 

LITERALLY 

'10. 

MAXSVPSiCPU 

LITERALLY 

'10'. 

MAX$CPU$$$MAX$VPS$CPU 

LITERALLY 

'100', 

FALSE 

LITERALLY 

'0', 

READY 

LITERALLY 

'1', 

RUNNING 

LITERALLY 

'3'. 

WAITING 

LITERALLY 

TRUE 

LITERALLY 

'119', 

NOT$FOUND 

LITERALLY 

'255', 

PORTAC0 

LITERALLY 

'00C0H ' , 

P0P.T$C2 

LITERALLY 

'00C2H', 

PORTSCE 

LITERALLY 

'00CEH', 

PORTSCC 

LITERALLY 

'00CCH' , 

RESET 

LITERALLY 

'0'. 

INTSRETURN 

LITERALLY 

'7?S ' , 

IDLE$STACK$SEG 

LITERALLY 

'0310E ' , 

IDLESSTACKSABS 

LITERALLY 

'03100H' , 

INIT$STACK$SEG 

LITERALLY 

'0320H  ' , 

INIT$STACK$ABS 

LITERALLY 

'03200H ' , 

MONlTOR$STACK$SEG 

LITERALLY 

'0330H'. 

MON I TORS STACKS ABS 

LITERALLY 

'03300H'; 

p 


1 

. 


J 
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/tQ^'tS#****#***#***#****#***#***********#*#****#**#***###**/ 


/*  PROCESSOR  DATA  SEGMENT  TABLE  */ 
/*  INFORMATION  RELEVANT  TO  THE  PARTICULAR  PHYSICAL  */ 
/*  PROCESSOR  ON  WHICH  IT  IS  RES IDENT .  */ 
/*  */ 
/*  CPU$NUMBER:  UNIQUE  SEQUENTIAL  NUMBER  ASSIGNED  TO  */ 
/*  THIS  REAL  PROCESSOR.  */ 
/*  VP$START:  VPM  INDEX  OF  THE  FIRST  VIRTUAL  */ 
/*  PROCESS  ASSIGNED  TO  THIS  REAL  CPU.  */ 
/*  VPAEND:  INDEX  IN  VPM  OF  LAST  VIRTUAL...  */ 
/*  VPS APERACPU :  THE  NUMBER  OF  VP  ASSIGNED  TO  THIS  */ 
/*  REAL  CPU.  MAX  IS  10.  */ 
/*  COUNTERS  AN  ARBITRARY  MEASURE  OF  PERFORMANCE.  */ 
/*  COUNT  MADE  WHILE  IN  IDLE  STATE.  */ 


DECLARE  PRDS  STRUCTURE 


CPUANUMBER 

BYTE, 

VPASTART 

BYTE, 

VP5END 

BYTE, 

VPSAPERACPU 

BYTE, 

COUNTER 

WORD) 

PUBLIC  INITIAL (0,0. 0,0.0) 


/*******************#*#**#*****************#***************/ 

/*  GLOBAL  DATA  BASE  DECLARATIONS  */ 
/*  DECLARED  PUBLIC  IN  FILE  'GLOBAL. SRC '  ♦/ 
/*  IN  MODULE  'GLOBALAMODULE'  */ 


DECLARE  VPM (  MAXACPUAAAAMAXAVPSSCPU  )  STRUCTURE 
( VPS  ID  BYTE, 


C<P  41»t* 

VPAPRIORITY 
EVCATHREAD 
EVCAAWAVALUE 
SS  A  REG 


BYTE, 

BYTE, 

BYTE, 


WORD. 

WORD)  external; 


DECLARE 

CPUAI NIT  BYTE  EXTERNAL, 

HDWAINTAFLAG(  MAX$CPU  )  BYTE  EXTERNAL, 

NR$VPS (  MAX$CPU  )  BYTE  EXTERNAL, 

NR$RPS  BYTE  EXTERNAL, 

globalalock  byte  external; 

DECLARE 

EVENTS  BYTE  EXTERNAL, 

EVC$TBL(100)  STRUCTURE 
(BVCANAME  BYTE, 

VALUE  WORD, 

THREAD  BYTE)  EXTERNAL; 


i 
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DECLARE 

SEQUENCERS  BYTE  EXTERNAL, 

SEQ$TABLE(100)  STRUCTURE 
(SEO$NAME  BYTE, 

SEQ$VALUS  WORD)  EXTERNAL; 

/*0145***** *'• ** ****** **  **************************#********#*/ 
/*  DECLARATION  OF  EXTERNAL  PROCEDURE  REFERENCES  */ 

/*  THE  FILE  AND  MODULE  WHERE  THEY  ARE  DEFINED  ARE  */ 

/*  LISTED.  */ 


INITI ALSPROC:  PROCEDURE  EXTERNAL;  END; 

/*  IN  FILE:  INITKX.SRC  */ 

/*  IN  MODULE:  INIT$M0D  */ 

AWAIT:  PROCEDURE  (EVC$ ID ,AWAITED$VALUE)  EXTERNAL? 

DECLARE  EVC$ID  BITS,  AWAITED$VALUS  WORD? 
end; 

VPSCHEDULER:  PROCEDURE  EXTERNAL?  END? 

/*  IN  FILE:  SCHED. ASM  */ 

DECLARE  INTVEC  LABEL  EXTERNAL? 

/*  IN  FILE:  SCHED. ASM  */ 

DECLARE  INTRSVSCTOR  POINTER  AT(0110H)  INITIAL (0INTVEC ) ; 

/*  IN  FILE:  SCHED. ASM  */ 

/*ei6Q*****************************************************/ 

/*  THESE  DIAGNOSTIC  MESSAGES  MAY  EVENTUALLY  BE  REMOVED.  */ 
/*  THE  UTILITY  PROCEDURES,  HOWEVER,  ARE  ALSO  USED  BY  THE  V 
/*  MONITOR  PROCESS.  THEY  SHOULD  NOT  BE  REMOVED.  */ 

DECLARE 

MSGli*)  BYTE  INITIAL  ('ENTERING  RETSVP  ',13,10,'%'), 
MSG1A(*)  BYTE  INITIAL  ('  RUNNING$VP$INDEX  =  %'), 

MSG4'*)  BYTE  INITIAL  ('ENTERING  RDYTHISV? ',13,10, '%') , 

MS G4A ( * )  BYTE  INITIAL  ('  SET  VP  TO  READY:  VP  »  %'), 

MS G7 ( * )  BYTE  INITIAL  ('ENTERING  GETWORK' ,13,10, '%') , 
MSG7A(*)  BYTE  INITIAL  ('  SET  VP  TO  RUNNING:  VP  »  %'), 

MS G7B(*)  BYTE  INITIAL  ('  SELECTED5DBR  =  %'), 

MSG10(*)  BYTE  INITIAL  ('ENTERING  IDLE$VP  '.13,10,'%'), 
MSG11 (*)  BYTE  INITIAL  ('UPDATE  IDLE  COUNT  ',13,10,'%'), 
MSG12 ( * )  BYTE  INITIAL  ('ENTERING  KERNEL$INIT ',10,13, '%') , 
MSG20(*)  BYTE  INITIAL  ('ENTERING  LOCATE$EVC  ',10,13,'%'), 
MSG22(*)  BYTE  INITIAL  ('ENTERING  LOCATE5SSQ  ',10,13,'%'), 
MSG23 (* )  3YTE  INITIAL  ('  FOUND' ,10 ,13 , '%' ) , 

MSG24(*)  BYTE  INITIAL  ('  NOT  FOUND ',10, 13, '%' ) ? 
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DECLARE 

CR  LITERALLY  '0DH  '♦ 

LF  LITERALLY  '0AH'? 

OUTACHAF :  PROCEDURE (  CHAR  )  EXTERNAL.’ 
DECLARE  CHAR  BYTE; 

end; 

OUT ALINE:  PROCEDURE(  LINE$PTP.  )  EXTERNAL 
DECLARE  LINE$PTR  POINTER? 
end; 

OUTANUM:  PROCEDURE(  NUM  )  EXTERNAL? 
DECLARE  NUM  BYTE? 

end; 

OUTADNUM:  PROCEDURE(  DNUM  )  EXTERNAL? 
DECLARE  DNUM  VORD? 

END? 

OUTAHEX:  PROCEDURES )  EXTERNAL; 

DECLARE  B  BYTE? 

END? 

INACHAR :  PROCEDURE  <  RET$PTR  )  EXTERNAL 
DECLARE  RETAPTR  POINTER? 

end; 

INADNUMj  PROCEDURE  (RETAPTR)  EXTERNAL? 
DECLARE  RETAPTR  POINTER? 

end; 

INANUM:  PROCEDURE  (RETAPTR)  EXTERNAL? 

DECLARE  RETAPTR  POINTER? 
end; 


5 
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/*0271****************** ************ ***********************/ 

/*  STACK  BATA  &  INITIALIAZTION  PCR  SYSTEM  PROCESSES  */ 


DECLARE  IDLESSTACK 

STRUCTURE 

(SP 

WORD, 

BP 

WORD, 

RET $ TYPE 

WORD, 

LENGTH (030H) 

WORD, 

DI 

WORD, 

SI 

WORD, 

DS 

WORD, 

DX 

WORD, 

CX 

WORD, 

AX 

WORD, 

BX 

WORD, 

ES 

WORD, 

START 

POINTER,  /*  IP.CS  */ 

PL 

WORD)'  AT  ( I DLE$STACK$ ABS  ) 

INITIAL( 

66H,  0,  I NT$ RETURN, 

0i0i0f0^0f0f0r0t0f9f3f0i0t0t0«0»0|0|090|0i0t0|0i 
0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 
0,0, 0,0, 0,0, 0,0,  0IDLE$PROC,  200H  )J 


DECLARE  INIT$STACK 
(SP 
BP 

RET$TYPE 
LENGTH (030H) 

DI 

SI 

BS 

DX 

CX 

AX 

9X 

ES 

START 

PL 

INITI AL(  66H 
0,0,0, 0,0, 0,0, 0,0,0 
0,0, 0,0, 0,0, 0,0, 0,0 
0,0, 0,0, 0,0, 0,0, 


STRUCTURE 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

POINTER,  /*  I?,CS  */ 

WORD)  AT ( I NIT$STACX$ABS ) 

,  0,  INT$RETURN, 

,0 ,0  ,0 ,0,0 ,0  ,0  ,0 ,0 ,0 ,0  ,0 ,0 ,0  , 
,0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 
(•INITIALS PROC ,  200H  ); 

/*  200H  SETS  THE  IP  PLAG  */ 
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DECLARE  MONITOR$STACK  STRUCTURE 


SP 

WORD, 

3P 

WORD, 

RET $ TYPE 

WORD, 

LENGTH (030H) 

WORD, 

DI 

WORD, 

SI 

WORD, 

DS 

WORD, 

DX 

WORD. 

cx 

WORD, 

AX 

WORD, 

BX 

WORD, 

ES 

WORD, 

START 

POINTER 

/*  IP.CS  */ 


PL 


WORD)  AT ( M0NIT0R$STACK$A3S ) 
INITI AL(66H,0, INT$RETURN  , 


VfWfl 


0,0,0, 0, 0,0* 0,0,0, 0,0,0* 0t0f0t0,0,0t0|0t0, 0,0,0, 

0,0.0. 0,0, 0,0,0,  (?MONITOR$PROC,  200H)J 


/*035?********#*****^#*********’M,*****,M‘,)‘*******,)‘*,)t**,Mt***/ 
/* *** ****** ********* **** ******** ********** ***** ************ / 


/*  RETAfP  PROCEDURE  ELI NEP  5-25-82  */ 

/*  USED  BY  THE  SCHEDULER  TO  FIND  OUT  WHAT  IS  THE  CURRENT  */ 
/*  RUNNING  PPOCESS.  IT'S  INDEX  IN  VPM  IS  RETURNED.  */ 

/* - */ 

/+  CALLS  MADE  TO:  OUT$HE X  OUT$CHAR  */ 


/**********************************************************/ 


RETSVP:  PROCEDURE  BYTE  REENTRANT  PUBLIC; 

DECLARE  RUNNING$?P$ INDEX  BYTE; 

CALL  OUTSLINE(OMSGI); 

/*  SEARCH  THE  fP  MAP  POR  RUNNING  PROCESS  INDEX  */ 

DO  RUN NING$VP$ INDEX  *  PRDS . YPASTART  TO  PRDS.VP$END; 

IP  YPM(  RUNNING$?P$INDEX  ) .STATE  =  RUNNING 
THEN  GO  TO  POUND; 
end;  /*  DO  */ 

POUND : 

CALL  OUT$LINE(OMSG1 A) • 

CALL  0UT$HEX(RUNNING$VP$INDEX); 

CALL  OUT$CHAR(CR) ; 

CALL  OUTSCHAR(LP); 

RETURN  RUNNING$YP$INDEX; 

END?  /*  RETAYP  PROCEDURE  */ 


/*0403*****************************************************/ 

/*  RDTTHISVP  PROCEDURE  XLINE?  5-25-82  */ 


/* - */ 

/*  CHANGES  A  VIRTUAL  PROCESSOR  STATE  TO  READY  */ 

/* - V 

/*  CALLS  MADE  TO:  OUT$HEX  OUT$CHAR  */ 


/ft*********#***********************************************/ 

RDTTHISVP:  PROCEDURE  REENTRANT  PUBLIC; 

DECLARE  VP  BYTE? 

CALL  OUT  $L I N E ( OMS G4  ) » 

VP  =  RET$VP; 

CALL  0UT$LINE(0MSG4A) i 
CALL  OUT$HEX(VP); 

CALL  OUT$CHAR(CR); 

CALL  OUT$CHAR(LF)t 
VPM(VP) .STATE  =  READY; 

return; 

END?  /*  RDTTHISVP  PROCEDURE  */ 
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/*046 9**************** ************************************* / 


/*  GETWORX  PROCEDURE  SLI NEE  5-25-32  */ 

/*  DETERMINES  THE  NEXT  SLIGI3LS  VIRTUAL  PROCESSOR  TO  RUN  */ 

/* - */ 

/*  CALLS  MADE  TO:  OUTS  CHAP.  OUTS  LINE  OUTSDNUM  */ 


/ft*#******##*****#*)!:##  if  j 

GETWORX:  PROCEDURE  WORD  REENTRANT  PUBLIC? 

DECLARE  (PRI ,N  ,1 )  BYTE; 

DECLARE  SELECTEDSDBR  WORD? 

DECLARE  DISPLAY  BYTE? 

CALL  OUT$LINE(0MSS7); 

PRI  =  255? 

DO  /*  SEARCH  VPM  EOR  ELIGIBLE  VIRTUAL  PROCESSOR  TO  RUN  */ 
I  *  PRDS.VPSSTART  TO  PRDS.VPSEND; 

IF  /*  THIS  VP'S  PRIORITY  IS  HIGHER  THAN  PRI  */ 

( ( 7PM( I ) . VP$PRIORITY  <=  PRI)  AND 
(VPM (I). STATE  =  READY))  THEN  DO; 

/*  SELECT  THIS  VIRTUAL  PROCESSOR  */ 

PRI  =  VPM(I)  .vp$priority; 

n  =  i; 

end;  /*  if  */ 

END;  /*  DO  LOOP  SEARCH  OF  VPM  */ 

/*  SET  SELECTED  VIRTUAL  PROCESSOR  */ 

V?M(N). STATE  =  RUNNING? 

SELECTEDSDBR  =  VPM( N ) .SSSREGJ 

CALL  OUT$LINE(0MSG7A) ; 

CALL  OUTSHEX(N); 

CALL  OUTSCHAR(CR) ; 

CALL  OUTSCHAR(LF) J 

CALL  OUTSLINE(0MSG7B); 

CALL  OUTSDNUM(SELECTEDSDBR); 

CALL  OUTSCHAR(CR) ; 

CALL  OUTSCHAR(LF) J 

RETURN  SELECTEDSDBR.* 

END;  /*  GETWORK  PROCEDURE  */ 
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/*0535*****************************************************/ 


/*  L0CATE$E7C  PROCEDURE  ELI  NEE  5-25-82  */ 

/*  FUNCTION  CALL.  RETURNS  THE  INDEX  IN  EVENTCOUNT  TABLE  */ 
/*  OF  THE  EVENT  NAME  PASSED  TO  IT.  */ 

/*  CALLS  MADE  TO:  OUT$CEAR  0UT$LINE  */ 


/ft###******#*****#**  i*#**********#***********##*************/ 

LOCATS$EVC :  PROCEDURE( EVENT$NAME )  BITE  REENTRANT  PUBLIC; 

DECLARE  EVENT$NAME  BITE* 

DECLARE  (MATCH, EVCTBL$I NDEX )  BYTE? 

CALL  OUT$LINE((?MSG20); 

MATCH  =  false; 

EVCTBL$INDEX  *  0J 

/*  SEARCH  DOWN  THE  EVENTCOUNT  TABLE  TO  LOCATE  THE  */ 

/*  DESIRED  EVENTCOUNT  BY  MATCHING  THE  NAMES  */ 

DO  WHILE  (MATCH  *  FALSE)  AND  ( EVCTBLSINDEX  <  EVENTS); 

/*  DO  WHILE  HAVE  NOT  FOUND  THE  EVENTCOUNT  AND  HAVE  NOT  */ 
/*  REACHED  END  OF  THE  TABLE  */ 

IF  £VENT$NAME  »  EVC$TBL (EVCTBL$INDEX) .EVCSNAME  THEN 
MATCH  *  TRUE; 

ELSE 

EVCTBL$INDEX  =  EVCTBL$I NDEX+1 ; 
end;  /*  WHILE  */ 

/*  IF  HAVE  FOUND  THE  EVENTCOUNT  */ 

IF  (MATCH  *  TRUE)  THEN  DO? 

/*  RETURN  ITS  INDEX  IN  THE  EVC$TBL  V 
CALL  0UT$LINE(0MSG23); 

RETURN  EVCTBL$INDEX; 

end; 

ELSE  do; 

/*  RETURN  NOT  FOUND  CODE  */ 

CALL  0UT$LINE((?MSG24) ; 

RETURN  NOT$FOUND; 

END;  /*  ELSE  */ 

END;  /*  LOCATE$BVC  PROCEDURE  */ 


120 


/*0601**************^*************************************/ 

/*  LOCATS$SEQ  PROCEDURE  KLINEF  5-23-32  */ 


_ r  ,.  ,  M  ^  ..  M  ww  M  y 

/*  JUNCTION  CALL  TO  RETURN  TEE  INDEX  OF  TEE  SEQUENCER  */ 
/*  SPECIFIED  IN  TEE  SEQ-TABLE.  */ 

/* - */ 

/*  CALLS  MADE  TO:  0UT$LINE  */ 


/ft******#***************#**##*#**#*#*****#***##***#******#* / 


LOCATE$SEQ:  PROCEDURE(SEQ$NAME )  BYTE  REENTRANT  PUBLIC. 

DECLARE  SE0$NAME  BYTE? 

DECLARE  (  MATCH,  SEQ.T3L$INDEX  )  BYTE? 

CALL  OUT$LI NE( 0MSG22 ) J 

MATCH  =  FALSE; 

SEQTBL$ INDEX  =  0J 

DO  WHILE  (MATCH  =  FALSE)  AND  (SEQTBL$INDEX  <  SEQUENCERS); 
IF  SEQ5NAME  =  SEQ$TABLE (SEQTBL$ INDEX ) .SEQ$NAME  TEEN 
MATCH  =  TRUE? 

ELSE 

SSQTBL$INDEX  =  SEQT£L$I NDEX  +  l; 

END;  /*  WHILE  */ 

IF  (MATCH  =  TRUE)  THEN  DO; 

CALL  0UT$LINEOMSG23); 

RETURN  SEQTBL$INDEXJ 
end;  /*  IF  V 
ELS  E  DO ! 

CALL  CUT$LINE(0MSG24); 

RETURN  NOT$FOUNDJ 
END;  /*  ESLE  */ 

END?  /*  LOCATE$SEQ  PROCEDURE  */ 
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/*066?*****************************************************/ 
/ft**#####**###*####*  ##  ##$###**#**#  / 

/*  SYSTEM  PROCESSES  */ 

/*  */ 


/it*#****#**********#******#*#**#**##*#****##*#*#**#*#*####*/ 

/*  IDLE  PROCESS  KLINE?  5-24-82  */ 

/* - */ 

/*  THIS  PROCESS  IS  SCHEDULED  I?  ALL  OTHER  PROCESSES  IN  */ 
/*  THE  VPM  ARE  BLOCKED.  THE  STARTING  ADDRESS  IS  PROVIDED*/ 
/*  TO  THE  IDLE$STACK  AND  PLACED  IN  PRDS.IDLESDBR.  A  */ 
/*  COUNTER  IS  INCREMENTED  ABOUT  EVERY  SECOND.  THE  COUNT  */ 
/*  IS  MAINTAINED  IN  THE  PRDS  TABLE  AND  IS  A  ROUGH  MEASURE*/ 
/*  OF  SYSTEM  PERFORMANCE  BY  GIVING  AN  INDICATION  OF  THE  */ 
/*  AMOUNT  OF  TIME  SPENT  IN  THE  IDLE  PROCESS.  */ 


/*  CALLS  MADE  TO:  PLM86  PROCEDURE  'TIME'  */ 

/*  OUT$LINE  */ 


/«**#*#*********************«**********«*******«***********/ 

IDLE$PROC :  PROCEDURE  REENTRANT  PUBLIC  » 

DECLARE  I  BYTE? 

CALL  OUT$LINE(0MSG10) ; 

/*  DELAYS  ONE  (1)  SECOND  */ 

LOOP:  DO  I  =  1  TO  40? 

CALL  TIME(  250  ); 

end; 

CALL  OUT$LI NE(0MSG11 ) ; 

PRDS. COUNTER  =  PRDS. COUNTER  +  1? 

GO  TO  loop; 

end;  /*  IDLE$PROC  */ 


/*0639**************^**  ***********************************/ 

/*  MONITOR  PROCESS  KLINEF  5-26-62  */ 

/*  THE  MONITOR  PROCESS  IS  INITIALIZED  BY  THE  OS  LIKE  */ 
/*  INIT  AND  IDLE.  IT  HAS  THE  RESERVED  ID  0?  0FEH  AND  A  */ 
/*  PRIORITY  OF  0H.  IT  IS  ALWAYS  BLOCKED  OR  WAITING  UNTIL*/ 
/*  IT  IS  PREEMTED  BY  THE  USER.  */ 


- - — - — - - - - #  / 

/*  CALLS  MADE  TO:  OUT$LINE  0UT$CHA3  */ 

/*  OUT$DNUM  I N$DNUM  */ 

/*  IN$NUM  */ 

/#*******#***#***#*»**«*#**#***********####*##***********#*  / 

MONITORSPROC :  PROCEDURE  REENTRANT  PUBLIC; 

DECLARE 

PTR  POINTER, 

PTR2  POINTER, 


PTR3  BASED  PTR 2  POINTER, 

ADDR  STRUCTURE  (OFFSET  WORD,  BASE  WORD), 

CONTENTS  BASED  PTR  BYTE; 

DECLARE 

(LINECOMPLETE,  L00P2)  BYTE. 

(QUANTITY,  COUNT)  BYTE, 

( INCHR ,  INDEX,  VALID$CMD)  BYTE? 

LOOP:  VALID$CMD  *  0} 

CALL  OUT $ CHAR ( CR ) J 
CALL  OUT$CHAR(LF ) » 

CALL  OUT$CHAR( '); 

DO  WHILE  NOT  VALID$CMD,* 

CALL  IN$CHAR( QINCHR) J 

IF  (INCHR  =  'D')  OR  (INCHR  =  'S')  OR  (INCHR  =  'E ' )  THEN 
VALID$CMD  =  OFFH; 

IF  (INCHR*64H)  OR  (INCHR=65H)  OR  (INCHR=73H)  THEN 
VALID$CMD  =  0FFHJ 

I?  VALID$CMD  *  0FFH  THEN  CALL  OUT$CHAR( INCHR) ; 

END;  /*  DO  WHILE  */ 
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IF  (INCHR  -  'D')  OR  ( INCHR  *  64H)  THEN  DO? 

/*  DISPLAY  COMMAND  SECTION  */ 

CALL  IN$DNUM(9ADDR.BASE)? 

CALL  OUT$CHAR (':')? 

CALL  IN$DNUM(9ADDR .OFFSET); 

PTR2  *  0ADDR? 

PTR  *  PTR3? 

/*  CONTENTS  SHOULD  NOW  BE  SET  */ 

DO  WHILE  (INCHROCR)  AND  ( INCHR023H)  ? 

CALL  IN$CHAR (9INCHR ) ? 

END?  /*  DO  WHILE  */ 

IF  INCHR  =  CR  THEN  DO? 

CALL  OUT$CHAR( '-')? 

CALL  OUT$NUM (CONTENTS)? 

CALL  OUT$CEAR(CR); 

CALL  OUT$CHAR(LF); 

END?  /*  IF  NORMAL  1  ADDR  DISPLAY  */ 

IF  INCHR  *  23 H  THEN  DO? 

COUNT  *  0? 

CALL  OUT$CHAR( '#')? 

CALL  IN$NUM(90UANTITY) ; 

DO  WHILE  QUANTITY  >  0? 

CALL  OUTS CHAR ( CR) ? 

CALL  OUT$CHAR(LF); 

CALL  OUT$DNUM( ADDR. BASE)? 

CALL  OUT$CHAR{ ')? 

CALL  OUT$DNUM( ADDR. OFFSET)? 

LINECOMPLETE  *  FALSE? 

DO  WHILE  LINECOMPLETE  *  FALSE,* 

CALL  OUT$CEAR('  ')? 

CALL  OUT$NUM( CONTENTS )? 

ADDR. OFFSET  *  ADDR. OFFSET  +  1? 

PTR  »  PTR3? 

OUANTITY  =  QUANTITY  -  1? 

IF  ( (ADDR. OFFSET  AND  000F3)=0)  OR 

(OUANTITY  =  0)  THEN  LINECCMPLETS=TRUE 
END?  /*  DO  WHILE  LINE  NOT  COMPLETE  */ 

END?  /*  DO  WHILE  QUANTITY  */ 

END?  /*  IF  MULTI  ADDR  DISPLAY  V 
END?  /*  DISPLAY  COMMAND  SECTION  */ 


IF  (INCER«'S')  OR  { I N CHR *73H )  THEN  DO? 

/*  SUBSTITUTE  COMMAND  SECTION  */ 

CALL  IN$DNUM( OADDR .BASE  )  * 

CALL  OUTACHAR  ( ' :  ) ; 

CALL  INADNUM( GADDR .CFFS3T ) » 

CALL  OUT$CHAR( 

PTR2  «  oaddr; 

PTR  -  PTR3* 

/♦  CURRENT  CONTENTS  SEOULD  NOW  BE  AVAILABLE  */ 
CALL  OUT$NUM( CONTENTS); 

L00P2  «  TRUE? 

DO  WHILE  L00P2  *  TRUE; 

DO  WHILE  ( INCHRO  ' »  ' )AND(INCHR<>  '  ') 
AND(INCHROCR); 

CALL  INACHAR(GINCER); 

end; 

IF  (INCHR  *  CR)  THEN  L00P2  *  FALSE; 

IF  (INCHR  *  ',')  THEN  DO; 

/*  SHIP  THIS  AD DR  AND  GO  TO  NEXT  FOR  SUB  */ 
CALL  OUT$CHAR(CR); 

CALL  OUT$CHAR(LF) ; 

ADDR. OFFSET  »  ADDR. OFFSET  +  1? 

PTR  *  PTR3; 

CALL  OUT$DNUM( ADDS. BASE); 

CALL  OUTACHAR( ':'); 

CALL  OUT$DNUM( ADDR. OFFSET); 

CALL  OUT$CHAR( '-'); 

CALL  OUT$NUM(CONTENTS)J 
END;  /*  IF  SKIP  FOR  NEXT  SUB  */ 

IF  (INCHR  *  '  ')  THEN  DO; 

CALL  OUTACHAR( '  '); 

CALL  IN$NUM(OCONTENTS ); 

DO  WHILE  ( I  NCHROCB)AND(  INCHRO','); 

CALL  IN$CHAR((?INCHR); 

end; 

IF  (INCHR  =  CR)  THEN  L00P2  =  FALSE; 

IF  (INCHR  =  V)  THEN  DO; 

CALL  OUTACEAR( ',')*» 

ADDR. OFFSET  =  ADDR. OFFSET  *  i; 

PTR  »  PTR3; 

CALL  OUT$CEAR(CR); 

CALL  OUT$CEAR(LF)J 
CALL  0UT$DNUM( ADDR. BASE) ; 

CALL  OUTACHAR ( ': '); 

CALL  OUT$DNUM( ADDR. OFFSET); 

CALL  0UTACEAR( '-'); 

CALL  OUTANUM ( CONTENTS ); 

END;  /*  IF  GO  TO  NEXT  ADDR  */ 

END;  /*  IF  CHANGE  CONTENTS  */ 

INCHR  »  'X'J  /*  REINITIALIZE  CMD  */ 


END;  /*  LOOP,  CONTINUOUS  SU3  CMD  */ 
END;  /*  SUBSTITUTE  COMMAND  SECTION  */ 

IF  (INCHR*'S')  OR  (INCHR=65H)  THEN  DO; 
/*  FIND  OUT  WHICH  VPS  IS  RUNNING  'ME 
INDEX  «  RET$VP; 

/*  NOW  BLOCK  MTSELF  */ 

7PM( INDEX). STATE  *  WAITING; 

CALL  VPSCHEDULERJ  /*  NO  RETURN  */ 

end;  /*  if  */ 

GO  TO  loop; 

end;  /*  MONITOR  PROCESS  */ 
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/* 0997****************** ****************** *****************  / 


/*  STARTING  POINT  CP  THE  OPERATING  SYSTEM  */ 

/* - */ 

/*  ROUTINE  INITIALIZES  THE  OS  AND  IS  NOT  REPEATED.  */ 


/****************:tt^  4*  ************ *************************/ 
/ft*********************************************************/ 

/*  TO  INITIALIZE  THE  PRDS  TABLE  FOR  THIS  CPU  */ 

DECLARE  CPU5PTR  POINTER  DAT A ( OPRDS .CPU$ NUMBER ) , 

ZZ  BYTE? 


disable; 

CALL  OUT$LINE(0MSG12 )* 

/*  INITIALIZE  P  P  I  AND  PIC*/ 

OUTPUT (PORTSCE)  *  80HJ /*  PPI  CONTROL  -  MAKE  PORT  C  OUTPUT  */ 
OUTPUT ( PORT $C0)  »  13HJ  /*  PIC  -  ICW1  -  EDGE  TRIGGERED  */ 
OUTPUT (P0RT$C2)  *  40H;/*  PIC  -  ICW2  -VECTOR  TABLE  ADDRESS  */ 
OUTPUT ( PORT $C2)  *  0FHJ /*  PIC  -  ICW4  -MCS86  MODE.  AUTO  EOI  */ 


/*  ESTABLISH  UNIQUE  SEQUENTIAL  NUMBER  POR  THIS  CPU  */ 
/*  SET  GLOBALUOCK  */ 

DO  WHILE  L0CK$SET(GGL0BAL$L0CK,119);  END; 

PRDS .CPU$NUMBER  *  CPU$INIT; 

CPU$I NIT  =  CPU$INIT  +  i; 

/*  RELEASE  GLOBAL  LOCK  */ 

GL03AL$L0CK  =  3f 

/*  SET  UP  INITIAL  START  AND  END  POR  PROC  TABLE  */ 
PRDS. VP$ START  =  0; 

DO  ZZ  -  1  TO  PRDS. CPU$ number; 

PRDS . VP$START  *  PRDS .7P$START  +  MAX$VPS$CPU; 

end; 

PRDS . VP$END  =  PRDS. VP$ START  +  2; 

PRDS . VPS $PE?$CPU  *  3; 

/*  INITIALIZE  THE  VP  MAP  FOR  IDLE  AND  INIT  PROC  */ 

/*  AND  MONITOR  PROCESS  */ 

V?M(PRDS.VP$START).VP$ID  =  255; 

V?M(PRDS.VP$START) .STATE  *  X; 
VPM(PRDS.VP$START).VP$PRIORITY  =  05 
VPM(PRDS .VPASTART) .EVC$THREAD  =  255; 
VPM(PRDS.VP$START) .EVC$AW$VALUE  *  05 
VPM(PRDS.VP$START).SS$REG  =  INIT$STACK$SEG; 
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VPM(?RDS.V?$START+1).VP$ID  =  255? 

7?M(PRDS.7?$START+1). STATE  =  1? 

7PM(PRDS.7P$START+1) .7P$PRI0RITY  »  255; 
7PM(?RDS.7P$START+1).E7C$THREAD  =  255? 

¥PM(PRDS.VP$START+1) .E7C$A¥$7ALUS  »  0; 

7?M(PRDS ,7P$START+1 ) .SSSREG  -  IDLE$STACK$SE&J 

7PM(PRDS.7P$START+2).7P$ID  «  0PEHJ 
7PM(PRDS.7P$START+2). STATE  »  7i 
7PM(PRDS.7P$START+2).7P$PRI0RITT  -  05 
7PM(PRDS .7P AS TART ♦2) .E7C$THREAD  «  255; 
7PM(PRDS.7P$START+2).E7C$A¥$7ALUE  *  0? 

7PM(PRDS.7P$START+2) .SSSREO  *  MONlTOR*STACK$SEG; 

NR$PPS  =  NR$RPS  +  15 
MR$7PS (PRDS  .CPU$NUMBER  )  =  3; 

HD¥$INT$FLAG(  PRDS .CPUSNUMBER  )  *  0  ; 

enable; 

CALL  7PSCHED0LERJ  /*  -  -  NO  RETURN  */ 

/*********************************«************************ / 
/***4^*4^***********«*#***********«******«*****************/ 


END?  /*  Ll$MOLULE  */ 

/4^>M<******4^*4^4^4^4ni^*********************************»«*/ 

/* ******************** *********4***********#****#**********/ 
/***u(^4^4^*4nfr******90^*$4^*4^*#**4***#*******4*****  #*****«*#/ 


ISIS-II  MCS-86  LOCATES,  VI, 1  INVOKED  BY: 
L0C86  KORE.LNK  ADDRESSES  (  SEGMENTS  (S. 
STACK(03000?),& 

INITMOD  CODE( 028? 0H) ,& 

GLOBALMODULE  DATA (0E0000?) ) )  5, 

SEGSIZE(  STACK(75H  ) 

?.S(0E  TO  0EEFH )  M«* 

WARNING  56:  SEGMENT  IN  RESER7ED  SPACE 
SEGMENT:  (NO  NAM?) 

SYMBOL  TABLE  OF  MODULE  L1MODULE 
READ  FROM  FILE  KORE.LNK 
WRITTEN  TO  FILS  :F0:KORE 


BASS 

OFFSET 

TYPE 

SYMBOL 

BASE 

OFFSET 

TYPE 

SYMBOL 

0240? 

000A? 

PUB 

PRDS 

0100? 

046A? 

PUB 

.MONITORPROC 

0100H 

0420H 

PUB 

IDLEPRCC 

0100F 

0381H 

PUB 

LOCATES EO 

0100H 

02E2H 

PUB 

LOCATEEVC 

0100? 

0217H 

PUB 

GETWORX 

0100E 

01C0E 

PUB 

RDYTHISVP 

0100? 

014EH 

PUB 

RETVP 

0182H 

0BB5H 

PUB 

OUTHEX 

0182? 

^  A30H 

PUB 

INHEX 

0182H 

0A60H 

PUB 

SENDCHAR 

0182? 

0A3DH 

PUB 

P.ECVCHAR 

0182E 

0A11H 

PUB 

OUTDNUM 

0182H 

09D8H 

PU3 

INENUM 

0182H 

09C0E 

PUB 

OUTNUM 

0182H 

0971? 

PUB 

OUTLINE 

0182H 

0959? 

PUB 

OUTC^AR 

0182? 

093  EH 

PUB 

INNUM 

0182E 

0923H 

PUB 

INCHAR 

0182H 

07DEH 

PUB 

CREATEPROC 

0182H 

0772H 

PUB 

TICKET 

0182F 

06ECH 

PUB 

CREATES EO 

0182H 

04E7W 

PUB 

PREEMPT 

0182? 

0334? 

PUB 

ADVANCE 

0182E 

027FH 

PUB 

AWAIT 

0182? 

020BH 

PUB 

READ 

ei82H 

ei80H 

PUB 

CPEATEEVC 

0192H 

0060? 

PUB 

GATEKEEPER 

0264H 

0000? 

PUB 

VPSCFEDULFR0264? 

003D? 

PUB 

INTVEC 

0280H 

0002H 

PUB 

INITIALPRCCE000R 

0190? 

PUB 

7  PM 

E000F 

04C9H 

PUB 

SEOT«BLE 

T000? 

04C8H 

PUB 

SEQUENCERS 

E000H 

04C7H 

PUB 

CPUINIT 

*000? 

0000? 

PUB 

EVCTBL 

E000H 

04C6H 

PUBEN 

rENTS 

E000H 

043CE 

PUB 

hdwintflag 

E000E 

04B2H 

PUB 

NRVPS 

E000H 

04B1H 

PUB 

NSRPS 

E000H 

04B0H 

PUB 

GLOBALLOCK 

MEMORY  MAP  OF  MODULE  L1MCDULS 
READ  FROM  FILE  KORE.LNK 
WRITTEN  TO  FILE  :F0:KORE 
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MO PUIS 

STABT  »rPR9S 

S  PARAGRAPH 

*  01009  093S3T 

=  0030H 

SEGMENT 

MAP 

START 

STOP 

LENGTH 

ALIGN 

NAME 

CLASS 

00110H 

001139 

00049 

A 

'ABSOLUTE) 

010009 

01B25H 

0826F 

W 

LI MODULE  CODE 

CODE 

018269 

024089 

0B339 

W 

L2M0DULB"C0DS 

CODE 

0240AH 

0240A9 

00009 

w 

GLCBALMOfULE  C 

CODE 

-ODE 

0240AH 

02S3BH 

01329 

w 

L1M0DULS  DATA 

DATA 

0253CH 

026199 

00349 

W 

L2M0DUL2~DATA 

DATA 

026209 

026309 

00139 

w 

INITMOD  DATA 

DATA 

026409 

026409 

00009 

* 

'J 

??SEG 

026409 

026909 

00A1H 

G 

SCHEDULER 

028009 

028249 

002  59 

W 

INITMOD  CODE 

CODE 

030009 

030749 

00759 

W 

STACK 

STACK 

031009 

031739 

007C9 

A 

(A3SCLUTE ) 

032009 

0327B9 

007CE 

t 

(ABSOLUTE) 

033009 

033739 

007C9 

A 

(ABSOLUTE) 

900009 

E05T49 

05959 

¥ 

GLCBALMODULE  D 

DATA 

-AT* 

305969 

E05F6H 

00009 

¥ 

MEMORY 

MEMORY 

APPENDIX  G 


SCHEDULER  &  INTERRUPT  HANDLER  SOURCE  CODE 

The  source  code  in  this  appendix  is  part  of  LEVEL  I,  but 
it  was  assembled  under  ASM86  instead  of  of  compiled.  No 
special  attributes  are  required  for  the  assembler.  The 
source  code  is  contained  in  file:  SCHED.ASM.  It  is  linked 
along  with  the  other  modules  of  LEVEL  I  and  LEVEL  II  into 
file:  KORE.LNK.  Its  memory  map  is  included  in  the  memory 


map  for  KORE. 


*********************************************************** 

*  SCHEDULER  ASM  FILE  KLINEF  2-27-82  * 

?*  THE  FOLLOWING  ARE  THE  EXTERNAL  PLM86  PROCEDURES  CALLED  * 

»*  BY  THIS  MODULE.  * 

EXTRN  GETWORK:FAR 
EXTRN  RDYTHISVP:FAR 
EXTRN  PRDSjBYTE 
EXTRN  HDWINTFLAGiBYTE 
EXTRN  GLOBALLOCK : BYTE 

SCHEDULER  SEGMENT 

PUBLIC  VPSCHEDULER 
PUBLIC  INTVEC 

VPSCHEDULER  PROC  FAR 

ASSUME  CS : SCHEDULER 
ASSUME  PS :NOTHING 
ASSUME  SStNOTHlNG 
ASSUME  ES:NOTHING 

J  ENTRY  POINT  FOR  A  CALL  TO  SCHEDULER 
CL  I 

PUSH  DS 
MOV  CX.0H 

;  SWAP  VIRTUAL  PROCESSORS.  TEIS  IS  ACCOMPLISHED  BY 
;  SAVING  THE  SP  AND  BP  REGISTERS  ON  THE  STACK,  ALONG 
J  WITH  THE  RETURN  TYPE  FLAG  AND  GETTING  A  NEW  '*DBR" , 

;  THE  SS  REGISTER  OR  STACK  SEGMENT  REGISTER  OF  THE 
?  PROCESS  SELECTED  TO  RUN  NEXT 

INTJOIN:  MOV  SS :WORD  PTR  0,SP  ?  SAVE  "CURRENT”  SP 
MOV  S S : WORD  PTR  2, BP  i  SITE  CURRENT'  BP 

MOV  SSjWORD  PTR  4,CX  ?  SAVE  IRET  IND  FLAG 

CALL  GSTWORK 

MOV  SS.AX  ?  SS :=  'SELECTED*  SS_REG 

J  SWAP  VIRTUAL  PROCESSOR  CONTEXT  COMPLETE  AT  THIS  POINT 
i  NOW  OPERATING  IN  NEWLY  SELECTED  PROCESS  STACK 
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MOV  SP, SSsWORD  PTH  0  ;  S?s=  SELECTED,'  SP 

MOV  BP.SS :W0RD  PTH  2  J  3P:=  SELECTED  BP 

MOV  CX,SS:WOHD  PTR  4 

;  CHECK  TOR  RETURN  TYPE.  NORMAL  OR  INTERRUPT 

CMP  CX.77H 
JZ  I  NT RET 

NORM  RETi  POP  DS 

J "UNLOCK  GLOBAL$LOCK 
MOV  AX.SEG  GLOBALLOCK 
MOV  ES ,  AX 
MOV  SS:GLOBALLOCK,0 

STI 

RET 

VPSCHEDOLER  ENDP 


i*  INTERRUPT  HANDLER  * 

;*  * 

INTER RUPT_HANDLER  PROC  NEAR 

ASSUME  CSiSCHEDULER 
ASSUME  DS; NOTHING 
ASSUME  SS:NOTHING 
ASSUME  ES;N0THING 

INTVEC:  CLI 

PUSH  ES  ;  SAVE  NEEDED  REGs  TO  TEST  INTERRUPT  FLAG 
PUSH  BX 
PUSH  AX 
PUSH  CX 

CALL  HARDWARE  INT  FLAG 
MOV  AL,0 

XCHG  AL.ES ;HDWINTFLAG[BX] 

CMP  AL.77H  J  IS  INT  FLAG  ON  ? 

JZ  PUSH  REST  REGS  J  IF  'YES'  SAVE  REST  REGs 


POP  cx 
POP  AX 
POP  BX 
POP  ES 
STI 
IRET 

PUSH_REST  REGS:  POSH  DX  i  FLAG  WAS  ON  SO  NEED 
PUSH  DS  ;  FE-SECHEDULE 

PUSH  SI 
PUSH  DI 

MOV  AX.SSG  GLOBAL  LOCK 
MOV  ES,  AX 

CK:  MOV  AL ,119  ?  LOCK  GLOBAL  LOCI 

LOCK  XCHG  ES :GLOBALLOCK , AL 
TEST  AL,AL 
JNZ  CK 

CALL  RDYTHIS VP 

MOV  CX,?7H  ;  JUMP  TO  SCHEDULER 

JMP  INT JOIN 

INTP.ET:  POP  DI 

POP  SI  J  RETURN  FOR 

POP  DS  J  PROCESS  WHICH 

POP  DX  ;  HAD  PREVIOUSLY 

POP  CX  ;  BEEN  INTERRUPTED 

?  UNLOCK  GLOBAL$LOCK 
MOV  AX.SEG  GLOBALLOCK 
MOV  ES.  AX 
MOV  ES: GLOBALLOCK, 0 


?  IF  'NOT  RESUME  PREVIOUS 
}  EXECUTION  POINT 


•  ft******************  4M***##*##*#*#*»***##***##>j(*j(!**:«:*#***##$# 

?*  HARDWARE  INTERRUPT  FLAG  * 

;*  * 

HARDW  ARE_INT_?LAG  PROC  NEAR 

ASSUME  CS {SCHEDULER 
ASSUME  DS {NOTHING 
ASSUME  SS { NOTHING 
ASSUME  ES {NOTHING 

HDW  FLAG{  MOV  AX.SIG  PRDS 
MOV  ES ,  AX 
MOV  BX,0H 

MOV  CL,ES  {PRDS  [BX]  JGET  CPU  # 

MOV  CH.0  5  RETURN  IN  BX 

MOV  BX.CX 

MOV  AX.SEG  HDWINTTLAG  JSET  UP  HDW$ INTSFLAG 
MOV  ES,  AX  .*  SEGMENT 

RET  J  RETURN  IN  ES  REG 

HAP.DWARE_INT_FLAG  ENDP 

SCHEDULER  ENDS 

END 


APPENDIX  H 


GLOBAL  DATA  BASE  AMD  INITIAL  PROCESS  CODE 

Two  files  are  presented  here:  GLOBAL. SRC  and  INITK.SRC. 
They  are  both  separately  compiled  with  the  LARGE  attribute. 
They  are  linked  into  the  file:  KORE.LNK.  They  are 
represented  in  the  memory  map  for  KORE  located  at  the  end  of 
Appendix  E.  INITK  reserves  only  the  minimum  amount  of  space 
required  by  operating  system  for  the  initial  process.  The 
user’s  initial  process  may  be  larger.  The  user  may  have  to 
explicitly  reserve  more  space  in  the  LOC86  command.  See  the 
file:  LOCP.CSD  for  an  example.  If  you  look  at  the  KORE 
memory  map  at  the  end  of  Appendix  F,  you  will  see  that  the 
INITMOD  CODE  segment  is  only  25H  bytes  long. 
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Z^##*##*##*#*#*#*####*:*#^**##*##*#  *##$$$#*  #«*«#*****##$##*#  / 
/It*#*#***#**#*##**#**##*#####*######*#*#*#####****#*#*#****  f 

/*0009  *****#******’-***#**********#*#**#*#**v*####*##**##*:*#*/ 
/*  PILE:  GLOBAL. SRC 

VERSION:  ELI  NEE  5-25-82 

PROCEDURES 

DEFINED:  NONE 

REMARKS :THIS  MODULE  CONTAINS  DECLARATIONS  FOR  ALL  THE 
GLOBAL  DATA  THAT  RESIDES  IN  SHARED  COMMON 
MEMORY.  IT'S  LOCATED  THERE  BY  THE  LOCATE  COM¬ 
MAND  AND  BY  SPECIFYING  THAT  THE 
GLOBAL$MODULE  DATA  SEGMENT  BE  LOCATED  AT  SOME 
ABSOLUTE  ADDRESS. 

♦/ 

/it**#*###**###*****######*#*##*#*#*#*##***##**####**#*##*##/ 


GLOBAL$MODULE:  DOi 

/it*********#****##*****##*###************#***#***********#*/' 

/ft*#************************#******************************/ 

/*  THE  FOLLOWING  THREE  LITERAL  DECLARATIONS  ARE  ALSO  */ 
/*  GIVEN  IN  TEE  LEVEL 1  &  LEVEL2  MODULES  OF  THE  OPERATING  */ 
/*  SYSTEM.  A  CHANGE  HERE  WOULD  HAVE  TO  BE  REFLECTED  IN  */ 
/*  THOSE  MODULES  ALSO.  */ 

DECLARE 

MAX$CPU  LITERALLY  '10', 

MAX$VPS$CPU  LITERALLY  '10', 

MAX$CPU$$S$MAX$VPS$CPU  LITERALLY  '100'; 

DECLARE 

GLOBAL$LOCK  BYTE  PUBLIC  INITIAL (0); 

/*  THIS  SHOULD  REFLECT  THE  MAX$CPU  ABOVE  */ 

DECLARE 

NR$RPS  BYTE  PUBLIC  INITIALS), 

NR$VPS (MAX$CPU)  BYTE  PUBLIC 

INITIAL (0 ,0, 0,0, 0,0, 0,0, 0,0); 


DECLARE  HDW$INT$FLAG(MAX$CPU)  3YTE  PUBLIC; 


DECLARE  EVENTS  BYTE  PUBLIC  INITIAL(l); 

DECLARE  EVC$TBL( 100)  STRUCTURE 
(EVCSNAME  BYTE, 

VALUE  WORD, 

THREAD  3YTE )  PUBLIC 

INITIAL(0FEH, 0,255); 

/*  EVC  ’FE*  IS  RESERVED  FOR  THE  OP  SYS  V 


DECLARE  CPUSINIT  BITE  PUBLIC  INITIALO); 


DECLARE 

SEQUENCERS 

BYTE  PUBLIC  INITIAL(0)J 

DECLARE 

SEQ$TABLE( 100) 

STRUCTURE 

( SEQ$NAME 

BYTE, 

SEQ$VALUE 

WORD)  public; 

DECLAHE 

7PM(  MAX$CPU$$$$MAX*VPS$CPU  )  STRUCTURE 

( VP$ID 

BYTE, 

V?$S TATE 

BITE, 

?P$PBIORITY 

BYTE, 

EV  C$THREAD 

BYTE, 

E7C$AW$VALUE 

WORD , 

SS$REG 

word)  public; 

END?  /*  MODULE  */ 

/fr*********^*********************  ****************  *#**#**♦*/ 


/**)M^********************4^****jMt******#********«***»*****/ 
/*  INITK  MODULE  ELI  NEE  5-27-82*/ 

/* - */ 

/*  THE  CODE  SEGMENT  0?  THIS  MODULE  IS  WHAT  RESERVES  SPACE  */ 

/*  BT  THE  OS  FOR  THE  USER  INITIAL  PROCESS.  THIS  IS  */ 

/*  EXECUTABLE  IN  IT'S  OWN  RIGHT.  THUS  IE  THE  USER  DOES  */ 

/*  NOT  PROVIDE  AN  INITIAL  PROCESS  THIS  ONE  WILL  EXECUTE,  */ 

/*  BLOCK  ITSELE,  AND  IDLE  THE  CPU.  THE  ADDRESS  OE  THE  */ 

/*  INITIAL  CODE  SEGMENT  IS  PROVIDED  TO  LEVEL1  AND  IT  IS  */ 

/*  REELECTED  IN  THE  PLM  LOCATE  COMMAND.  THE  ADDRESSES  */ 

/*  PROVIDED  MUST  AGREE.  THIS  PROCESS  HAS  THE  HIGHEST  */ 

/*  PRIORITY  AND  WILL  ALWAYS  BE  SCHEDULED  FIRST  BY  THE  */ 

/*  SCHEDULER .  */ 

/* - - 


/*  CALLS  MADE  TO:  AWAIT  */ 

/I*********************************************************/ 

INIT$M0D:  DO? 

DECLARE 

MSG13 (*)  BYTE  INITIAL (10, 'ENTERING  INITIAL  PROCESS 

13,10,'%'); 

OUT$LINE :  PROCEDURE (  PTR  )  EXTERNAL; 

DECLARE  PTR  POINTER; 

end; 

AWAIT:  PROCEDURE (  NAME,  VALUE  )  EXTERNAL; 

DECLARE  NAME  BYTE,  VALUE  WORD; 

end; 

INITIAL$PR0C :  PROCEDURE  PUBLIC; 

DECLARE  I  BYTE; 


/*  AETER  INITIALIZATION  THIS  PROCESS  BLOCKS  */ 
/*  ITSELE  TO  ALLOW  THE  NEWLY  CREATED  PROCESSES  */ 
/*  TO  BE  SCHEDULED.  */ 
/*  THIS  AREA  SHOULD  BE  WRITTEN  OVER  BY  USER  INIT  */ 
/*  PROCEDURE  MODULE.  */ 


CALL  0UT$LINE((?MSG13); 

CALL  AWAIT(  0EEH ,  1); 

END;  /*  INITI AL$PROC  */ 
end;  /*  INTTSMOD  */ 
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APPENDIX  I 


USER  GATE  MODULE  SOURCE  CODE 

This  source  code  is  contained  in  file:  GATE. SRC.  It  is 
compiled  with  the  attribute  LARGE.  The  object  code  file: 
GATE. OBJ  is  given  to  the  user  to  link  with  his  initial 
process  and  user  processes. 
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/*0007************************** ***************************/ 

/*  SATE  MODULE  EILE  'GATE. SRC'  KLINNEF  5-26-32  */ 

/*  THIS  MODULE  IS  GIVEN  TO  THE  USER  IN  OBJ  FORM  TO  LINK  */ 
/*  WITH  HIS  INITIAL  AND  PROCESS  MODULES.  ANT  CHANGES  TO  */ 
/*  USER  SERVICES  AVAILABLE  FROM  THE  OS  HAVE  TO  BE  */ 

/*  REFLECTED  HERE.  IN  THIS  WAY  THE  USER  DOES  NOT  HAVE  TO*/ 
/*  BE  CONCERNED  WITH  ACTUAL  GATEKEEPER  SERVICES  CODES.  */ 


/*  ALL  CALLS  ARE  MADE  TO  THE  GATEKEEPER  IN  LEVEL2  OF  THE  */ 
/*  OS.  THE  ADDRESS  OF  THE  GATEKEEPER  MUST  BE  GIVEN  BELOW.*/ 

/* 0018***************************************************** / 

GATES MOD :  DO; 

/*  REFLECT  GATEKEEPER  ADDRESS  HERE.  GKl=OFFSET ,  GK2=3ASE  */ 
DECLARE  (GK1.GK2)  WORD  DATA(0060H,0182H) , 

GATESKEEPER  POINTER  AT(OGKl); 

DECLARE  RETS  WORD, 

RETS$PTR  POINTER  DATAORETS); 

/*0029************** ****************************** *********/ 

AWAITS  PROCEDURE (  NAME,  COUNT  )  PUBLIC i 
DECLARE  NAME  BYTE,  COUNT  WORD? 

CALL  GATE$KEEPER(  0,  NAME,  COUNT,  0,  0); 

RETURN? 

end;  /*  AWAIT  */ 

/*0037**************** **************************** *********/ 

ADVANCE:  PROCEDURE!  NAME  )  PUBLIC. 

DECLARE  NAME  BYTE; 

CALL  GATE$KEEPER(  1,  NAME,  0,  0,  0  ),' 

return; 

end;  /*  ADVANCE  */ 

/*00 4 5************** ************** *************************/ 

CREATESEVC:  PROCEDURE!  NAME  )  PUBLIC; 

DECLARE  NAME  BYTE; 

CALL  GATESKEEPSR!  2,  NAME,  0,  0,  0  ); 

return; 

END,*  /*  CREATE $E VC  */ 


CREATESSEQ :  ?ROCEDURE(  NAME  )  PUBLIC  ? 

DECLARE  NAME  BITE? 

CALL  GATE$KEEPER(  3f  NAME,  0,  0,  0  ); 

return; 

end;  /*  createsseq  */ 

/*0081************** ********************** *****************/ 


TICKET:  PROCEDURE (  NAME  )  WORD  PUBLIC; 

DECLARE  NAME  BYTE; 

CALL  GATE$KEEPER(  4,  NAME.  0,  RETSSPTR  ) J 
RETURN  RETS? 
end;  /*  TICKET  */ 

/*00B9************** ***************************************/ 


READ:  PROCEDURE (  NAME  )  WORD  PUBLIC; 

DECLARE  NAME  BYTE; 

CALL  GATESKEEPER (  5,  NAME,  0,  RETSSPTR  )? 

RETURN  RETS? 

END;  /*  READ  */ 

/*0097******************************************** *********/ 


CREATESPROC:  PROCEDURE(  PROCSID,  PROCSPRI,  PROCSSTACKSLOC , 

PROCSIP,  PROCSCS  )  PUBLIC? 
DECLARE  (  PROCSID,  PROCSPRI  )  BYTE. 

(PROCSSTACKSLOC,  PROCSIP,  PROCSCS  )  WORD; 

DECLARE  PROCSTABLE  STRUCTURE 


(PROCSID  BYTE, 

PROCSPRI  BYTE, 

PROCSSTACKSSEG  WORD, 
PROCSIP  WORD, 

PROCSCS  WORD); 


DECLARE  PROCSPTP.  POINTER  DATA (OPROC STABLE ) ; 

PROCSTABLE. PROCSID  =  PROCSID? 

PROCSTABLE. PROCSPRI  =  PROCSPRI; 

PROCSTABLE. PROCSSTACKSSEG  -  PROCSSTACKSLOC  /  10H; 
PROCSTABLE. PROCSIP  =  PROCSIP? 

PROCSTABLE. PROCSCS  =  PROCSCS? 

CALL  GATESKEEPER(  6,  0,  0,  PROCSPTR  )? 

RETURN? 

END?  /*  CREATESPROC  */ 


142 


i 


/* 0139******************** *********************************/ 


OUTSCHAR :  PROCEDURE!  CHAR  )  PUBLIC; 

DECLARE  CHAR  BYTE* 

CALL  GATEKEEPER!  9,  CHAR,  0.  0,  0)? 

return; 

end; 

/*0147************** ************ ***************************/ 

OUT$LINE:  PROCEDURE!  LINE$PTR  )  PUBLIC; 

DECLARE  LINE$PTR  POINTER; 

/*  LINE  MUST  END  WITH  '%'  */ 

/*  AND  BE  LESS  THAN  80  CHAR  */ 

CALL  GATE$KEEPER(  9,  0,  0,  LINESPTR); 

return; 

end; 


/*0157** ***************************************************/ 


OUT$NUM:  PROCEDURE!  NUM  )  PUBLIC;  /**  NUM  IS  BYTE  **/ 
DECLARE  NUM  BYTE; 

CALL  GATE$KSEPER(  10.  NUM,  0,  0,  0  ); 
return; 
end; 

/*0165************** ************ ***************************/ 

OUTSDNUM!  PROCEDURE!  DNUM  )  PUBLIC?  /**  DNUM  IS  WORD  **/ 
DECLARE  DNUM  WORD?  /**  DOUBLE  BYTE  **/ 

CALL  GATEKEEPER (  11,  0,  DNUM,  0,  0  ); 
return; 


PREEMPT:  PROCEDURE!  PROC$ID  )  PUBLIC? 
DECLARE  PROC5ID  BYTE? 

CALL  GATE$KEEPER(  7,  PROC$ID,  0,  0,  0  )? 
RETURN? 

END?  /*  PREEMPT  */ 


/*01 91****************** ************************** *********/ 


IN$CHAR:  PROCEDURE  !RET$PTR)  PUBLIC? 
DECLARE  RET$PTR  POINTER? 

CALL  GATEKEEPER (12,  0.0,  RET$PTR ) J 

end; 
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/*02?5*****************************************************/ 


IN$NUM:  PROCEDURE  ( RET$PTR  )  PUBLIC.* 

DECLARE  RET$PTR  POINTER. 

CALL  GATEKEEPER (13,  0,  0,  RET$PTR) » 

END; 

/*Q21 2***************************************************** / 

IN$DNU*:  PROCEDURE  (RET$PTR)  PUBLIC.* 

DECLARE  RET$PTR  POINTER; 

CALL  GATEKEEPER (14,  0,  0,  RET$PTR )  J 

end; 

/********** *****^*9^  ***************************************/ 

END;  /*  GATE$MOD  */ 

/g*****^***^*******  .Ml**#******#***************************/ 

/******************«***************************************/ 
/ft***^*************:**#*##***********#******#***#**********  / 


APPENDIX  J 


USER  PROCESSES  I 

This  appendix  has  three  parts.  It  contains  the  source 
code  for  one  of  the  user  initial  processes,  INIT1.SRC.  The 
source  code  in  file,  PR0C1.SRC,  is  provided.  They  are 
separately  compiled  with  the  LARGE  attribute.  They  are 
linked  into  P01.LNK  and  the  memory  map  from  file,  P01.MP2, 
is  provided.  The  executable  code  file  P01  is  loaded  onto 


one  of  the  SBC's. 
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I-  /*  INITIAL  PROCESSS  P-1  KLINEF  5-27-82  */ 

I  /* - */ 

T  .  /*  THE  CODE  SEGMENT  OP  THIS  MODULE  WILL  BE  OVERLAYED  ON  */ 

/  /*  A  SEGMENT  RESERVED  BY  TEE  OS.  THIS  INITIAL  PROCESS  */ 

/*  WILL  CREATE  ALL  THE  PROCESS  THAT  WILL  RESIDE  ON  A  REAL*/ 
/*  PROCESSOR.  ALL  CALL  TO  CREATE$PROCESS  MUST  3E  MADE  */ 

/*  POR  EACH  PROCESS.  */ 

1  /*  CALLS  MADE  TO:  CREATE$?ROC  &  AWAIT'TO  BLOCK  INIT)  */ 

L  /if!*#***###*********#****#****************##******#*##*#*#**  / 

INI T$MODULE :  DO; 

CREATE$PROC:  PROCEDURE (  PROC$ID,  PRCC$PRI, 

J  PROC$STACK$LOC,  PROC$IP,  PROCSCS  )  EXTERNAL; 

DECLARE  (  PROC$ID,  PROC$PRI  )  BYTE, 

(PROC$STACK$LOC,  PROC$IP,  PROC^CS)  WORD? 

end; 

AWAIT:  ?ROCEDURE(  EVC$ID,  VALUE  )  EXTERNAL; 

DFCLARE  EVC$ID  BYTE, 

VALUE  word; 

end; 

INIT:  PROCEDURE  PUBLIC; 

/#4^*j|^**#***********#**  #**********************************/ 

/*  *  *  *  USER  AREA  OF  RESPONSIBILITY  **»**#/ 

/*  MUST  MAKE  CALL  FOR  EACH  PROCESS  TO  BE  CREATED.  USER  */ 
/*  PROVIDES  ALL  PARAMETERS.  */ 


CALL  CSEATEAPROC (  1,  253,  7000H,  06H,  720H  ),' 


/«#****#**** ^t*******^***#**#*******#*#******##*#:**#***#**  / 

/*  *  *  *  END  OF  USER  RESPCNS I3LITY  *  *  *  */ 

/*************************«************«************#****#* / 

/*  THIS  STATEMENT  BLOCKS  THIS  PROCESS  AND  ALLOWS  */ 

/*  THE  NEWLY  CREATED  PROCESSES  TO  BE  SCHEDULED.  */ 

CALI  AWAIT (  0FEH,  1  ); 

END;  /*  PROCEDURE  */ 

END;  /*  MODULE  */ 
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/**************#***********#*******#***#********#**********/ 
^****:M^************ ****** ***#***************#«************/ 

/*  PARAMETERS: 

PP.OC$ID:  (BYTE)  DESIRED  ID  POR  PROCESS.  'PE '  IS  RESERVED. 

PROC$PRI s  (BYTE)  DESIRED  PRIORITY.  HIGH  IS  0. 

LOW  IS  255. 

PROC$STACK$LOC:  (WORD)  ABSOLUTE  ADDRESS  OP  STACK .  MUST  HAVE 
ACCESS  TO  120H  BYTES  OF  PREE  SPACE. 

USER  PROCESS  MUST  BE  CODED  IN  PROCEDURE  BLOCK. 
THE  OS  PROVIDES  STACK  OP  110H  BYTES. 

PROCSIP:  (WORD)  USER  PROCESS  STARTING  ADDRESS  OFFSET. 

PROC$CS:  (WORD)  USER  PROCESS  STARTING  ADDRESS  BASE.  */ 

/#*********#**3M>************************** *****************/ 


/ft**##*#***#***#********##*#**********#***#***#*#*****#****  J 

/*  PROCESS  1  MODULE  KLINEF  6-1-82  */ 

/* - */ 

/*  THIS  IS  BASED  ON  THE  ORIGINAL  DEMONSTRATION  THAT  COX  */ 

/*  RAN.  */ 

/*  */ 

/*  IMPORTANT!  AFTER  LINKING  AND  LOCATING  THIS  MODULE,  */ 

/*  THE  ABSOLUTE  ADDRESS  OF  THE  PROCEDURE  BLOCK  LABEL,  */ 
/*  '?1'  MUST  BE  REFLECTED  IN  THE  INITIAL  PROCESS  IN  FILE:  */ 
/*  INIT1.SRC  */ 


CSUPP$MODULS:  DO; 

DECLARE  I  WORD? 

DECLARE  CR  LITERALLY  '0DE', 

LF  LITERALLY  '0AH'J 

DECLARE  K  WORD? 


DECLARE  CSUPP  BYTE  DATA (33); 

DECLARE  FLDES  BYTE  DATA(44 ) i 
DECLARE  NEW  BYTE  DATA  1 99H ) • 

/**********»***************«**********#**«*#**###**«**#*##*  / 


DECL/ R  ^ 

MSGl ( * )  BYTE  INITIAL! 'PROC  #1.  INITIAL  ENTRY  INTO', 
'CLUTTER  SUPPRESSION ',10, 13, '%'), 

MSG2( *)  BYTE  I NI TI AL ( 'PROC  #1.  WAIT  FOR  DATA  READY', 
10.13,'%'), 

MSG3  (* )  BYTE  IN  ITIAL(  '  PP.OC  #1.  PERFORMING  CLUTTER', 
'  SUPPRESSION:  FRAME  #  %'), 

MSG4 ( * )  BYTE  INITIAL! 'PROC  #1.  ADVANCE  FILTER  ', 
'DESIGN  EVENT  COUNT' ,10,13, '%') , 

MSG5 ( * )  BYTE  INITIAL! 'PROC  #1.  CALLED  READ  TWICE.', 
'  RETURNED:  %'), 

MSG6 (* )  BYTE  IN ITIAL! 'PROC  #1.  CALLED  TICKET', 

'  TWICE.  SECOND  VALUE  RETURNED:  %'), 

MSG7 ! * )  3YTS  INITIAL;10,13, '%'); 
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/***##»***#«####**#*#***#*¥#*$##*****#*#*##*##****##******* / 


AWAIT:  PROCEDURE! EVC SID .AWAIT EDS VALUE)  EXTERNAL? 
DECLARE  EVC$ ID  BYTE, 

4WAITED$ VALUE  WORD? 

END? 

ADVANCE:  ?ROCEDURE!EVC$ID)  EXTERNAL? 

DECLARE  EVC$ ID  BYTE; 

END? 

CREATE$EVC:  PRCCEDURE(  NAME  )  EXTERNAL? 

DECLARE  NAME  BYTE? 

END? 


CREATE$SEO:  PROCEDURE!  NAME  )  EXTERNAL? 

DECLARE  NAME  BYTE? 

END? 

TICKET:  PROCEDURE!  NAME  )  WORD  EXTERNAL? 

DECLARE  NAME  BYTE? 

END? 


READ:  PROCEDURE!  NAME  )  WORD  EXTERNAL? 
DECLARE  NAME  BYTE? 

end; 

OUTSCHAR:  PROCEDURE! CHAR)  EXTERNAL? 
DECLARE  CHAR  BYTE? 

end; 

OUT$NUM:  PROCEDURE!  NUM  )  EXTERNAL? 
DECLARE  NUM  BYTE? 

end; 

CUTSDNUM:  PROCEDURE!  DNUM  )  EXTERNAL? 

DECLARE  DNUM  WORD? 

END? 


OUT$LI NE :  PROCEDURE!  LINE$PTR  )  EXTERNAL? 

DECLARE  LINESPTP  POINTER? 

END? 


/ft####*#*########**}}:#*#*###*#*#####*#**#######**##  ##$*###*#  / 


PI:  PROCEDURE  PU3LIC  * 

CALL  OUT $ LI NE ( 0MSG1  )  ? 

/*  CREATE  SYNCHRONIZATION  PRIMITIVES  */ 

CALL  C RE ATE$EVC (CSUPP  ) » 

CALL  CREATE$5VC(PLDES); 

/*  CALL  READ  AS  A  TEST  */ 

K  *  READ (  CSUPP); 

CALL  OUT$LINE(  GMSG5  ); 

CALL  OUT$DNUM(  K  )J 
CALL  OUT$LINE(GMSG7); 

/*  CREATE  SEQUENCER  PRIMITIVES  */ 

CALL  CREATE$SEO(NSW ) J 

/*  CALL  TICKET  TWICE  AS  A  TEST  */ 

K  *  TICKET (NEW  )  * 

K  =  TICKET(NEW); 

CALL  0UT$LINE( GMSG6  ) » 

CALL  OUT$DNUM(  K  )? 

CALL  OUT$LlNE(GMSG7)J 

/*******$**##*#****#***#*«**********#*******<(********«#*  f 

/*  PROCESS  1  LOOP  BEGINS  HERE  */ 

I  *  15 

DO  WHILE  (I  <=  0FFFFH); 

CALL  0UT$LINE(GMSG2); 

CALL  AWAIT ( CSUPP  ,  I  )? 

I  -  I  +  15  /*  <========  */ 

CALL  0UT$LINE(GMSG3) ? 

CALL  OUT$DNUM{ I ) » 

CALL  0UT$LINE(GMSG7); 

DO  K  =  0  TO  1000? 

CALL  TIME ( 250  )  * 

end; 


CALL  OUT$LINE(0MSG4); 
CALL  ADVANCE(FLDES ) J 
END,*  /*  WHILE  */ 

end;  /*  pi  */ 

END?  /*  MODULE  */ 
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isis-ii  vcs-?e  locate? ,  vi.i  invoked  ^y? 

L0C86  P01.LWK  ADD=ESS?S (SEGMENTS (? 
INITMODULI  CODE'' 328^05)  .5, 

CSUPPMCDULi  CODE ' 072005  )  .& 
CSU??MCDULE_DAT A  (  0750CS  '  ,& 

GATEMOD  005  5(077*0^  ,5, 

GATEMOr~DATA '  079E05  )  ,& 

S TACK { 070005) ) )& 

SEGSIZE( STACK ' 100H )  )L 
RS ( 0  TO  27EEH ) 

SYMBOL  TABLE  CT  MODULE  INITMODULE 
READ  FROM  FI Lr  P01.LNK 
WRITTEN  TO  FILE  :F0:?01 


BASE 

OFFS  ET 

TYPE 

SYMBOL 

B»SE 

OFFSET 

TYPE 

SYMBOL 

0280H 

00025 

PUB 

INIT 

07205 

3006H 

PUB 

?1 

07705 

022D* 

PUR 

INPNUM 

07705 

020CE 

PUB 

INNUM 

0770E 

01SB5 

PUB 

INCHAr 

0770? 

01C05 

PUB 

PREEMPT 

0770H 

01  Ac  5 

PUB 

CUTDNUM 

077  05 

01855 

PUB 

CUTNUM 

07705 

0164H 

PUB 

OUTLINE 

0770P 

0141H 

PU3 

CUTCHAR 

3 7705 

00T4H 

PUE 

CFEATFP50C 

0770  ? 

00C8E 

PUB 

READ 

07703 

00SC5 

PU3 

TICKET 

07705 

0079* 

PUB 

CRSATESEO 

07705 

0056E 

PUB 

C?E»TEEVC 

0770? 

0033H 

PUB 

ADVANCE 

07705 

320EH 

PUB 

AWAIT 

MEMORY  MAP  OF  MODULE  INITMODUL* 
READ  FROM  FILE  ?*1 .LMK 
WRITTEN  TO  FILE  :F?:?01 


SEGMENT  MAP 


START 

STOP 

LENGTH 

ALIGN 

N  AME 

CLASS 

02800H 

02830H 

00315 

W 

INITMODULE_COD 

—  T  “ 

CODE 

02832H 

02832H 

00005 

W 

INI TMODULE  DAT 
-A 

STACK 

DATA 

07000E 

070FF5 

01005 

W 

STACK 

07200H 

07  3  2D  E 

012E5 

w 

CSUPPMODULE  CO 
— D  ~ 

CODE 

07500H 

0761CH 

011D5 

V 

CSUPPMOrULE  DA 
-T  A 

DATA 

077005 

0794DH 

024E5 

w 

GATEMOD  CODE 

CODE 

079E0H 

079ESF 

000A5 

w 

GATEMOD"DATA 

LATA 

079EAH 

0797?  H 

00005 

w 

MEMORY 

MEMORY 

APPENDIX  K 


F>  USER  PROCESSES  II 

}  ■ 

This  appendix  has  three  parts.  It  contains  the  source 

i 

f  code  for  one  of  the  user  initial  processes,  INIT2.SRC.  The 

J  source  code  for  user  processes  in  files,  PR0C2.SRC, 

PR0C3.SRC,  and  PR0C5.SRC  is  provided.  They  are  all  linked 
into  file,  P02.LNK.  The  executable  code  file,  P02  is  loaded 

onto  one  of  the  SBC's.  The  memory  map  in  file,  P02.MP2,  is 

t 

[  also  provided. 

; . 

L-. 

! 

r’ 

)  • 
i 
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1 


/*  INITIAL  PROCESS 


P-2  ?  *S 

-  fc  •  o  t  %J 


KLINSF  6-1,32  */ 


/* - */ 

/*  THE  CCDS  SEGMENT  OF  THIS  MODULE  WILL  3E  0V2RLAY2D  ON  */ 
/*  A  SEGMENT  RESERVED  3T  TEE  OS.  THIS  INITIAL  PROCESS  */ 
/*  WILL  CREATE  ALL  THE  PROCESSES  THAT  WILL  RESIDE  ON  A  */ 
/*  REAL  PROCESSOR.  ALL  CALLS  TO  CR3ATE$PRCCSSS  MUST  3E  */ 


/*  MADE  FOR  EACH  PROCESS.  */ 

/* - */ 

/*  CALLS  MADE  TO:  CREATE$PROC  &  AWAIT (TO  BLOCK  I  NIT)  */ 


/***#*****«******#**********#*#***********#****«****#******  / 


INITSMODULE :  DO; 


CREATE$?ROC :  PROCEDURE (  PROC$ID,  PROCSPRI, 

PROC$STACK$LOC ,  PROCSIP,  PROCSCS  )  EXTERNAL; 

DECLARE  (  PROC$ID,  PROC$?RI  )  BYTE, 

( PROC$STACK$LOC ,  PROCSIP,  PROC<CS)  WORD? 

end; 

a  AWAIT:  PROCEDURE(  EVC$ID,  VALUE  )  EXTERNAL? 

'  DECLARE  EVCSID  BYTE, 

VALUE  word; 

end; 

IN  IT:  PROCEDURE  PUBLIC ; 

^  /it***####*#*#*#*#*****#*##**#############*####*#*#**##*###*  / 

/*  *  *  *  USER  AREA  OF  RESPONSIBILITY  *♦*#**/ 

/*  MUST  MAKE  CALL  FOR  EACH  PROCESS  TO  3S  CREATED.  USER  */ 
/*  PROVIDES  ALL  PARAMETERS.  */ 


CALL  CP.EATSSPROC (  2,  245,  7000H,  04H,  720H  )J 

CALL  CREATE$PROC (  3,  253,  9000H,  04H,  920H  ); 

CALL  CREATE$PROC (  5,  254,  9000H,  06H,  820H  )J 

/I********#**#*#***********#*##*#**#***#*****#*#****###**#*'*  / 

/*  *  *  *  END  OF  USER  RESPONSIBLITY  *  *  *  */ 


/*  THIS  STATEMENT  BLOCKS  THIS  PROCESS  AND  ALLOWS  V 
/*  THE  NEWLY  CREATED  PROCESSES  TO  BE  SCHEDULED.  */ 

CALL  AWAIT (  0FEH,  1  )J 

END?  /*  PROCEDURE  */ 


END;  /*  MODULE  */ 

4 
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i 


/**********************************************************/ 
^S**#  *******************:!-.*  *#***'.*  ******  ****  **  **  ********  *****  f 

/*  PARAMETERS : 

?ROC$ID:  (BYTE)  DESIRED  ID  FOR  PROCESS.  'EE '  IS  RESERVED. 

PROC$PRI:  (BYTE)  DESIRED  PRIORITY.  HIGH  IS  0. 

LOW  IS  255. 

PROC$STACK$LOC :  (WORD)  ABSOLUTE  ADDRESS  OF  STACK.  MUST  HAVE 
ACCESS  TO  120H  BYTES  OF  FREE  SPACE. 

USER  PROCESS  MUST  BE  CODED  IN  PROCEDURE  BLOCK. 
THE  OS  PROVIDES  STACK  CF  1105  BYTES. 

PROCAIP:  (WORD)  USER  PROCESS  STARTING  ADDRESS  OFFSET. 

PROC$CS:  (WORD)  USER  PROCESS  STARTING  ADDPESS  BASS.  */ 

/**********************************************************/ 
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/**aM‘******************************************#******«**** / 

/*  PROCESS  2  MODULE  KLINE?  6-2-62  */ 

/* - */ 

/*  THIS  IS  BASED  ON  THE  ORIGINAL  DEMONSTRATION  THAT  CCX  */ 
/*  RAN.  */ 

/*  */ 

/*  IMPORTANT!  ONCE  THIS  MODULE  IS  LINKED  AND  LOCATED,  */ 

/*  THE  ABSOLUTE  ADDRESS  0?  THE  PROCEDURE  BLOCK  LABEL,  */ 

/*  'P02 '  MUST  BE  REFLECTED  IN  THE  INITIAL  PROCESS  IN  FILE:4/ 
/*  INIT2.SRC  */ 

/*********************************************************#/ 

FLDES$MODULE:  DOi 

DECLARE  I  WORD; 

DECLARE  Z  BYTE* 

DECLARE  CSUPP  BYTE  DATA (33); 

DECLARE  FLDES  BYTE  DATA (44),* 

/it*********************************************************  / 


DECLARE 


MSG1(4)  BYTE  INITIAL* 'PROC  #2. 

'  FILTER  DESIGN  ',13,10,  '% ') , 
MSG2(4)  BYTE  INITIAL* 'PROC  #2. 
13,10,'%'), 

MS G3 ( 4 )  BYTE  INI TI AL ( 'PROC  #2. 

'DESIGN  ON  FRAME  #  %'), 
MSG4(4)  BYTE  I NITI AL( 'PROC  #2. 

'SUPPRESSION  EVENT  COUNT', 10, 
MSG5(4)  BYTE  INITIALU0 ,13  , '%'  ) ; 


INITIAL  ENTRY  INTO', 

WAIT  FOR  DATA  READY' 

PERFORMING  FILTER  ', 

ADVANCE  CLUTTER  ', 
13,'%'). 


« 


/*^*****************************************************#** / 


AWAIT:  PROCEDURE(EVC$ID,AWAITSD$VALUE)  EXTERNAL? 
DECLARE  EVC$ID  BYTE, 

AWAITED$VALUE  WORD: 

end; 

ADVANCE:  PROCEDURE(EVC$ID)  EXTERNAL; 

DECLARE  EVC$ID  BYTE? 

end; 

CREATE$EVC:  PROCEDURE( NAME )  EXTERNAL; 

DECLARE  NAME  BYTE? 

end; 

0UT$LINE :  ?ROCEDURE( PTR )  EXTERNAL? 

DECLARE  PTR  POINTER? 

END; 
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OUT$DNUM:  PROCEDURE ( DNUM )  EXTERNAL; 

DECLARE  DNUM  WORD; 

end; 

/tfluM'.M'**********************************#****#************/ 

P2:  PROCEDURE  PUBLIC. 

CALL  OUT$LINE( 0MSG1 ) » 

/*  CREATE  THE  SYNCHRONIZATION  PRIMITIVES  »/ 

CALL  CREATE$EVC (CSUPP ) . 

CALL  CREATE$EVC(ELDES  )t 

/ft*************************************************  *****  / 

/*  BEGIN  PROCESS  2  LOOP  HERE  */ 

I  *  0; 

DO  WHILE  (I  <*  0TTTFE); 

CALL  0UT$LINE(0MSG2)J 

CALL  await(fldes.i); 

I*I+i; 

CALL  0UT$LINE((?MSG3)i 
CALL  OUTADNUM(I); 

CALL  OUT$LINE(0MSG5); 

DO  Z  *  0  TO  100; 

CALL  TIME(250)J 

end; 

CALL  OUT$LINE( 0MSG4) » 

CALL  ADVANCE( CSUPP); 

END;  /*  WHILE  */ 
end;  /*  P2  */ 
end;  /^module  v 
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/ft*********************************************************  / 

/*  PROCESS  3  MODULE  KLINE?  6-2-62  */ 

/* - */ 

/*  IMPORTANT!  ONCE  THIS  MODULE  IS  LINKED  AND  LOCATED,  */ 
/*  THE  ABSOLUTE  ADDRESS  OF  THE  PROCEDURE  BLOCK  LABEL,  V 

/*  'P03'  MUST  BE  REFLECTED  IN  THE  INITIAL  PROCESS  IN  FILE:*/ 
/*  INIT2.SRC.  */ 

/*************************************#********************/ 

?LDES3$M0DULE:  DO? 

DECLARE  I  WORD.* 

DECLARE  CR  LITERALLY  '0DH ', 

LF  LITERALLY  '0AH'J 
DECLARE  1  BYTE; 

DECLARE  FLDES  BYTE  DATA (44); 

/********4^*’^*****«****3Mt*********#*4^*>it***#*************#/ 

DECLARE 

MSG1! *)  BYTE  INITIAL(  'PROC  #3.  INITIAL  ENTRY', 

'  INTO  FILTER  DESIGN  PART  2 '  ,10,13, '% ' ) , 

MSG2( * )  BYTE  INITI AL( 'PROC  #3.  WAIT  FOR  DATA', 

'  READY', 10. 13,  '%'), 

MSG3( *)  BYTE  INITIAL(  'PROC  #3.  PERFORMING  PART  2', 

'  FILTER  DESIGN  ON  FRAME  #  %'), 

MSG4( *)  BITE  I NI TI AL ( 10 , 13 ,  ; 

/***4^*********#**** ****************************** *****4***/ 

AWAIT:  PROCEDURE! EVC$ID ,AWAITED$ VALUE)  EXTERNAL; 

DECLARE  EVC$ID  BYTE, 

AWAITED$7AL0E  WORD; 

end; 

ADVANCE:  PROCEDURE (EVC$ID)  EXTERNAL; 

DECLARE  EV  C  $  I D  BYTE; 

end; 

CHEAT E$EV C :  PROCEDURE( NAME )  EXTERNAL; 

DECLARE  NAME  BYTE; 

end; 

OUTLINE:  PROCEDURE! PTR )  EXTERNAL; 

DECLARE  PTR  POINTER? 

end; 

OUT$DNUM:  PROCEDURE! DNUM )  EXTERNAL; 

DECLARE  DNUM  WORD? 

end; 


/ft*#********##*#*#*##*** ft###*#**###*****####**#*#*##**#**#* / 

P3 :  PROCEDURE  PUBLIC? 


CALL  CUT$LINE(0MSG1 ) ? 

/*  CREATE  THE  SYNCHRONIZATION  PRIMITIVES  */ 
CALL  CREATE$2VC(FLDES ) ? 


/ft********#**#**###****##**#**####*#*#*##*###*###*******/ 

/*  PROCESS  3  LOOP  BEGINS  HERE  */ 


I  *  1? 

DO  WHILE  (I  <=  0FFFFH ) ? 


CALL  OUT$LINE(0MSG2 ) ? 


CALL  AWAIT (FLDES ,1 )? 
1=1+1? 

CALL  OUT$LINE(0MSG3) ? 
CALL  OUT$DNUM(I); 

CALL  OUT$LINE(0MSG4) ? 

DO  Z  *  0  TO  50? 

CALL  TIME(250 ) ? 
END? 

END?  /*  WHILE  */ 

END?  /*  P3  */ 

END?  /^MODULE  */ 


/ ft*##*#**####**##### $#>)(#  :;:$******#$#*#**#**$# $$**$##****$**#  f 

/*  PROCESS  5  MODULE  KLINE?  6-2-82  */ 

/*  THIS  PROCESS  ACCOMPLISHES  TESTS  0?  THE  OPERATING  SYSTEM*/ 
/*  NOT  YET  DONE.  ALL  0?  THE  NEWLY  ADDED  INPUT  SERVICES  */ 
/*  WILL  BE  TESTED  HERE  BEFORE  THE  PROCESS  GOES  INTO  IT 'S  */ 
/*  LOOP.  THIS  INCLUDES  PREEMT.  */ 

/*  THIS  PROCESS  ACTS  ON  DATA  LOCATED  IN  A  BUFFER  IN  */ 

/*  SHARED  COMMMON  MEMORY.  PROCESS  4  ,  RESIDENT  IN  SOME  */ 
/*  OTHER  CPU,  WILL  OUTPUT  THE  DATA  AFTER  IT  HAS  3EEN  PRO-  */ 
/*  CESSED.  THE  EFFECT  WILL  BE  EVIDENT  ON  THE  SCREEN  IF  */ 
/*  THEY  COORDINATE  CORRECTLY.  */ 

/*  */ 

/*  IMPORTANT!  AFTER  LINKING  AND  LOCATING  THIS  MODULE,  */ 

/*  MAKE  SURE  THE  ABSOLUTE  ADDRESS  OF  THE  PROCEDURE  BLOCK  */ 
/*  LABEL,  'P05 ' ,  HAS  BEEN  REFLECTED  IN  THE  INITIAL  PRO-  */ 
/*  CESS  IN  FILE  INIT2.WRK  */ 

/ft*********#**********#**************************#*********/ 


PR0C5SM0DULE:  DO? 


DECLARE 

I 

FOREVER 

MONITOR 

INCHR 

WCRD$VALUE 
BYTES VALUE 
GLOBALSBUFFER (70 ) 
LOCALS BUFFER  (70) 
PR0C4S5SEVC1 
?R0C4$5$EVC2 


BYTE.  K  WORD, 
LITERALLY  '0FFH ' , 
LITERALLY  '0FEH' , 
BYTE. 

WORD, 

BYTE 

BYTs’aT  ( 0E0700H ) , 
BYTE 

BYTE’iNITIAL  ( 10H) , 
BYTE  INITIAL  (11H); 


DECLA  RE 

MSG1 ( * )  BYTE  INITIAL(  'PROC  *5.  INITIAL  ENTRY% ' ) , 

MSG2 ! * )  BYTE  INITIAL(10,13 , 'PROC  #5.  PROCESSING  DATA', 

'  IN  SHAPED  BUFFER%' ) , 

MSG3( *)  BYTE  INITIAL(10,13,  'PROC  #5.  FINI5EED  PROCESS', 
'ING',13,10,'%')  , 

MSG4( * )  BYTE  I NITIAL( 10 . 13 , 'DC  YOU  WANT  TO  PREEMPT  THE', 
'  MONITOR ( Y  OR  N )?%' ) * 

MSG9(  * )  BYTE  INITIALS.  10 ,  13  , '%  ' )  J 


/*************«**************»***************************** / 


AWAIT:  PROCEDURE(EVC$ ID, A WAITED $ VALUE)  EXTERNAL; 
DECLARE  EVC$ ID  BYTE,  AWAITED$VALUE  BYTE? 

end; 


ADVANCE:  PROCEDURE*  SVC$ID)  EXTERNAL* 
DECLARE  EVC$ID  BYTE; 

end; 

CREATSAEVC :  PROCEDURE  ( NAME )  EXTERNAL.* 
DECLARE  NAME  BYTE; 

end; 


CREATE$SEQ:  PROCEDURE  ( NAME )  EXTERNAL.* 
DECLARE  NAME  BYTE; 

end; 

OUTSCHAP ;  PROCEDURE (CHAR)  EXTERNAL? 
DECLARE  CHAR  BYTE? 

end; 

IN$CHAR:  PROCEDURE( RET$PTR )  EXTERNAL? 
DECLARE  RET$PTR  POINTER? 

end; 

PREEMPT:  PROCEDURE* VP$ID)  EXTERNAL? 
DECLARE  VP$ID  BYTE? 

end; 

OUTSLINE:  PROCEDURE ( PTR )  EXTERNAL? 
DECLARE  PTR  POINTER? 

end; 


INSNUM:  PROCEDURE ( RET$PTR )  EXTERNAL; 
DECLARE  RETS PTR  POINTER? 

end: 


INSDNUM:  PROCEDURE (RETS PTR)  EXTERNAL? 
DECLARE  RETSPTR  POINTER? 

end; 

OUT$DNUM: PROCEDURE (WORDS )  EXTERNAL? 

DECLARE  WORDS  WORD? 
end; 

OUTSNUM:  PROCEDURE ( B YT )  EXTERNAL? 

DECLARE  BYT  BYTE? 
end; 
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/* ********************************************************* / 


P5:  PROCEDURE  PUBLIC; 

CALL  OUT$LINE(0MSG1  ); 

CALL  CREATE$EVC(PROC4$5$EVCl); 

CALL  CREATE$SVC(PR0C4$5$EVC2) ; 

DO  I  *  0  TO  69? 

GLOBAL*BU?FER(I)  = 

end; 

GLOBAL$BUFFER(0 )  =  'X'i 

K  *  0t 

/*************#**************  I******#**********#********#/ 

/*  PROCESS  5  LOOP  BEGINS  HERE  */ 

DO  WHILE  FOREVER; 

CALL  AWAIT(PR0C4$5$EVC1,K) ; 

IF  X  =  35  THEN  CALL  PREEMPT ( MON I TOR ) i 
I  =  E  +  i; 

CALL  OUT$LINE( GMSG2 ) 5 
DO  I  =  0  TO  69? 

L0CAL$3UFFER( I )  =  GL03AL$BUFFER( I ) » 

end; 

I  =  0? 

DO  WHILE  LOCAL$BUFFER(I )  <>  'X'? 

I*I+i; 

end; 

IF  I  =  69  THEN  LOC AL$BUFFER( 0)  =  'X'J 
ELSE  LOCAL$BUFFER  ( I  +1)  *  'X'; 

LOCAL$BUFFER ( I )  * 

DO  I  *  0  TO  69; 

GLOBAL5BUFFER (I )  =  LOCAL$BUFFER(I ) J 

end; 

CALL  OUT$LINE( 0MSG3) J 
CALL  ADVANCE(PR0C4$5SEVC2) ; 

END?  /*  DC  FOREVER  */ 

END;  /*  P5  */ 

END;  /*  PROC5$MODULE  */ 
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ISIS-II  MCS -86  10 CATER ,  VI. 1  INVOKED  BY: 
L0C56  P02  .LNK  ADDRESSES  '  SEGMENTS  ( S. 

IN ITMCDULE  CORE ( ?2800H)  .& 

«  FLDSSMCDULS  CODE^  )  ,& 

*  *  FLDSSMCDULE~DATA  '  0'7500H  )  ,& 

GATEMOD  CODE (V777Z1L)  ,& 

GATEMOD  j)  AT A (079E051  ,& 

PR0C5M0DULE  CODE '  08200H )  ,& 

PR0C5M0DULE  D*T » f  08500H  1,& 

|  FLDSS3M0DULE  CODE ( 292005 ) , & 

-  FLDES3M0DULE  DATA '09500? ),  &. 

STACK { 772???] ) )S 
SEGSIZS( STACK ( 100H  '  )& 

RS ( 0  TO  27FEH) 

I  SYMBOL  TABLE  OF  MODULE  INITMODULE 

READ  FROM  FILE  P02.LNK 
WRITTEN  TO  FILE  :?0i?02 


BASE 

OFFSET 

TYPE 

SYMBOL 

BASE 

OFFSET 

TYPE 

02e0H 

00025 

PUP 

IMIT 

07205 

0004H 

PUB 

0920H 

0004H 

PUR 

?3 

0820F 

0006H 

PU3 

0770H 

022DF 

PU* 

INDNUM 

0770H 

720CH 

PUB 

0770E 

01E3H 

PUB 

INCHAR 

07705 

01C83 

PUB 

0770H 

01A8H 

PUB 

OUTDNUM 

0770^ 

0195H 

PU3 

07705 

01643 

PUB 

OUTLINE 

07^03 

01413 

PUB 

0770H 

00E43 

PUB 

CREATEPROC 

07705 

00C8H 

PUB 

0770H 

009C3 

PUB 

TICKFT 

0079H 

PUB 

0770H 

00565 

PUP 

CREATES VC 

07705 

0033H 

PUB 

0770H 

000EH 

PUB 

AWAIT 

I  MEMORY  MAP  OF  MODULE  IN ITMODULF 

P  READ  FROM  FILE  P02.LNK 

I  WRITTEN  TO  FILE  :70:P02 


SYM30L 

P2 

P5 

INNUM 

PREEMPT 

CUTNUM 

OCTCBAR 

READ 

CRSATESEC 

ADVANCE 
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SEGMENT  Mr P 


START 

S  TCP 

LENGTH 

ALIGN 

NAME 

CLASS 

02800E 

0235FH 

005EH 

¥ 

IMITMODULE  COD 
— E 

CODE 

02860H 

02860H 

0000H 

w 

INITM0DULE_DAT 

•  A 

DATA 

07000H 

07 0FFF 

0100H 

w 

STACK 

STACK 

07200H 

072R5H 

0036H 

v 

FLDESMOrULE  CO 

CODE 

07500H 

075E5H 

005  6H 

V 

-DF 

FLDESMCDULE  DA 

DATA 

07700E 

C794DH 

024FH 

w 

-TA 

J4TEMCD  CODE 

CODE 

079E0H 

079S9H 

000  AH 

w 

GAT  erod'd ATA 

DATA 

08200H 

08341H 

0142E 

¥ 

PECC5MGDULE  CO 

CODE 

08500H 

085E6H 

03E7H 

V 

-DE 

PPCC5M0DULE  DA 

DATA 

09200B 

09296H 

7C97E 

w 

-TA 

FLDES3M0DULE  C 

CODE 

0S500H 

0958FE 

0090H 

w 

-ODE 

FLrES3M0DULE_D 

-®TA 

(ABSOLUTE) 

MEMORY 

DATA 

E0700H 

E0746H 

E0745H 
20746 H 

0046E 

0000H 

A 

¥ 

M2M0R 

APPENDIX  L 
USER  PROCESSES  III 


This  appendix  has  three  parts.  It  contains  the  source 
code  for  one  of  the  user  initial  processes,  INIT3.SRC.  The 
source  code  for  user  processes  in  file,  PR0C4.SRC,  is 
provided.  They  are  all  linked  into  file,  P03-LNK.  The 
executable  code  file,  P03  is  loaded  onto  one  of  the  SBC's. 
The  memory  map  in  file,  P03-MP2,  is  also  provided. 
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/**«#*###*$#*********#**#**#**#*»**********#**«************ / 

/*  INITIAL  PROCESSS  P-4  KLINEF  5-27-62  */ 

/*  THE  CODE  SEGMENT  OP  THIS  MODULE  WILL  BE  OVERLAYED  ON  */ 
/*  A  SEGMENT  RESERVED  BY  THE  OS.  THIS  INITIAL  PROCESS  */ 
/*  WILL  CREATE  ALL  THE  PROCESS  THAT  WILL  RESIDE  ON  A  REAL*/ 
/*  PROCESSOR.  ALL  CALL  TO  CREATE$PROCESS  MUST  BE  MADE  */ 


/*  FOR  EACH  PROCESS.  */ 


/*  CALLS  MADE  TO:  CREATE$PF.OC  &  AWAIT(TO  BLOCK  I  NIT )  */ 

/lie**********************  #*****#***#*******$***#***#**#*#**>!(  J 


INIT$M0DULE :  DO? 

CREATE$PROC:  PROCEDURE (  PROC$ID,  PROC$PRI, 

PROC$STACK$LOC.  PROCSIP,  PROC$CS  )  EXTERNAL? 

DECLARE  (  PROC$ ID «  PROCSPRI  )  BYTE, 

( PROC$STACK$LOC ,  PROC$IP,  PROC$CS)  WORD? 

END? 

AWAIT:  PROCEDURE (  SVC$ID,  VALUE  )  EXTERNAL? 

DECLARE  EVC$ID  BYTE, 

VALUE  WORD? 

END? 

IN  IT:  PROCEDURE  PUBLIC? 

/*******4^********** ******#********************************/ 
/*  *  *  *  USER  AREA  OF  RESPONSIBILITY  ******/ 

/*  MUST  MAKE  CALL  FOR  EACH  PROCESS  TO  3E  CREATED.  USSR  */ 
/*  PROVIDES  ALL  PARAMETERS.  */ 

/I**********************************************************  / 


CALL  CREATEiPROC (4,  5,  7000H,  06H,  0720H  )? 


/##**#*****#*##**’**##*****#****##********#*******»*********  / 

/*  *  *  *  END  OF  USER  RESP0NSI3LITY  *  *  *  */ 

/itftiM'****^*##**#****#*  ************  ft********)****************/ 


/*  THIS  STATEMENT  BLOCKS  THIS  PROCESS  AND  ALLOWS  */ 
/*  THE  NEWLY  CREATED  PROCESSES  TO  BE  SCHEDULED.  */ 


CALL  AW  A I T (  0FEH,  1  )? 
END?  /*  PROCEDURE  */ 


END?  /*  MODULE  */ 
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/it^****:**##**##********#  ###*****  ##?###***#***#****#**«*##**  / 

/*  PARAMETERS : 

PROC$ID:  (BYTE)  DESIRED  ID  FOR  PROCESS.  'FE '  IS  RESERVED. 

PROC$ PRI :  (BYTE)  DESIRED  PRIORITY.  HIGH  IS  0. 

LOW  IS  255. 

?ROC$STACK$LOC :  (WORD)  ABSOLUTE  ADDRESS  OF  STACK.  MUST  HAVE 
ACCESS  TO  120H  BYTES  OF  FREE  SPACE. 

USER  PROCESS  MUST  BE  CODED  IN  PROCEDURE  BLOCK. 
THE  OS  PROVIDES  STACK  OF  110H  BYTES. 

PROC$IP:  (WORD)  USER  PROCESS  STARTING  ADDRESS  OFFSET. 

?ROC$CS :  (WORD)  USER  PROCESS  STARTING  ADDRESS  BASE.  */ 

/##***#****4**#********4**:tr**#*#******#**#******r#*#*#****#jr/ 
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/**#*»##*##***####$**#**#*#****e#9#****#*****¥:ic#>)t  $*#****«#«*  / 

/*  PROCESS  4  MODULE  KLINEF  6-2-82  */ 

/* - */ 

/*  IMPORTANT!  AFTER  LINKING  AND  LOCATING  THIS  MODULE,  */ 


/*  MAKE  SURE  THE  ABSOLUTE  ADDRESS  OF  THE  PROCEDURE  BLOCK  */ 
/*  LABEL,  'P05',  HAS  3SEN  REFLECTED  IN  THE  INITIAL  PRC-  */ 
/*  CESS  IN  FILE  INIT2.VRK  */ 


/******:**** e******J)c*#  #*#*#*##**>***********#****♦**####*##***  j 


PRCC4$MODULE:  DO? 


DECLARE 

( I , J)  BYTE,  K  WORD, 

FOREVER  LITERALLY  '0FFH  '  , 

GLOBAL$BUFFER  ( 70 )  BYTE  AT  (0E0700H), 

LOCAL$BUFFER  (70)  BYTE, 

PR0C4$5$EVC1  3YTE  INITIAL  (10H), 

?R0C4$5$EVC2  BYTE  INITIAL  (11H)? 

y^*****^******#*?******#*****************#*******#*********/ 

% 

DEC LA  3E 

MSG9 ( * )  BYTE  INITIAL^ 10 , 13 ,  '%')t 

/#*#**«** t****#aM^***:M«  *************************************/ 


AWAIT s  PROCEDURE (EVC$ ID, AWAITED$VALUE)  EXTERNAL? 

DECLARE  EVC$ID  BYTE,  AWAITED5VALUE  BYTE? 

END? 

ADVANCE;  PRCCEDURE(EVC$ID)  EXTERNAL? 

DECLARE  EVCUD  BYTE? 

END? 

CREATE$EVC:  PROCEDURE ; NAME )  EXTERNAL? 

DECLARE  NAME  BYTE? 

END? 

OUTSCHAR:  PROCEDURE (CHAR )  EXTERNAL? 

DECLARE  CHAR  BYTE? 

END? 

OUTALINE;  PROCEDURE (PTR )  EXTERNAL? 

DECLARE  PTR  POINTER? 

END? 
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P4:  PROCEDURE  PUBLIC? 


CALL  CREATE$SVC(PR0C4$5$EVC1) ? 

CALL  CREATE$EVC(PR0C4$5$EVC2) ? 
/*«*****$***#***###*#******#**?#*#**#####*$*#***#**#**** / 
/*  PROCESS  5  LOOP  BEGINS  HERE  */ 


K  =  0001 H? 

DO  WHILE  FOREVER? 

CALL  AWAIT ( PR0C4$5$EVC2 ,K ) ? 

K  *  K  +  1? 

DO  I  =  0  TO  69? 

LOCAL$BUFFER(I )  =  GLOBAL$BUFFER( I ) * 


END? 

DO  I  =  0  TO  69? 

CALL  0UT$C3AR (LOCALSBUFFER ( I ) )  ? 
END? 

CALL  0UT$LINE( 0MSG9) ? 

DO  I  =  0  TO  255? 

CALL  TIME (250 ) ? 

END? 

CALL  ADVANCE(PR0C4$5$E7C1) ? 

END?  /*  DO  FOREVER  */ 

END?  /*  P4  */ 

END?  /*  ?R-0C4$M0DULE  */ 


ISIS-I I  MCS-26  LOCATOR,  71.1  INVOKED  3Y: 
L0C36  P03.LNK  ADDRESSES  ( SEGMENTS ( & 
INITMODULE  CODE(026003) ,& 

PR0C4MCDULE  CODE ( 72Z0H ) ,& 
?ROC4MODULE~DATM75?0H)  ,& 

STACK (70005J ) )& 

SECS  I ZE( STACK { 100E ) )& 

?S(e  TO  71FFH ) 

WARNING  £6:  SEGMENT  IN  RESERVED  SPACE 
SEGMENT:  INITMODULE  CCDS 
WARNING  56:  SEGMENT  IN  RESERVED  SPACE 
SEGMENT:  STACK 

SYMBOL  TABLE  07  MODULE  INITMODULE 
PEAD  FROM  FILE  P03.LNK 
WRITTEN  TO  FILE  :F0:?03 


BASE 

OFFS  ST 

TYPE 

SYMBOL 

BASE 

OFFSET 

TYPE 

SYMBOL 

0280H 

0002H 

PUB 

INIT 

072  0H 

0006H 

PUB 

P4 

0755E 

022DH 

PUB 

INDNUM 

0755H 

020CH 

PUB 

INNUM 

0755H 

01EBH 

PUB 

INCHAR 

0755H 

01C8H 

PUB 

PREEMPT 

0755H 

01A93 

PUB 

OUTDNUM 

07555 

0185H 

PUB 

OUTNUM 

0755H 

0164H 

PUB 

OUTLINE 

07555 

0141H 

PUB 

OUTCHAR 

0755H 

00F4H 

PUB 

CREATEPRCC 

075  55 

00C8H 

PUB 

READ 

0755H 

009CH 

PUB 

TICKET 

0755H 

0079H 

PUB 

CREATESEO 

0755H 

0755H 

0056H 

000EH 

PUB 

PUB 

CREATEEVC 

AWAIT 

0755H 

0033B 

PUB 

ADVANCE 

MEMORY  MAP  OF  MODULE  INITMODULE 
READ  FROM  FILE  P03.LNK 
WRITTEN  TO  FILE  :F0:P03 

SEGMENT  MAP 


START 

STOP 

LENGTH 

ALIGN 

NAME 

CLASS 

02800H 

02830H 

0031H 

W 

INITMODULE  COD 

— F 

CODE 

07000H 

070FFH 

0100H 

W 

STACK 

STACK 

07200H 

072C2H 

00C3H 

W 

PR0C4M0DULE  CO 
-DE 

CODE 

072C4H 

072C4H 

0000H 

W 

INITMODULE  DAT 

-A 

GATEMOD  DATA 

DATA 

072C4H 

072CDH 

000AH 

W 

DATA 

07500H 

0754EH 

004  FH 

w 

PR0C4M0CULE  DA 
-TA 

DATA 

07550H 

0779DH 

024EH 

w 

GATEMOD  CODE 

CODE 

E0700H 

E0745H 

0046H 

A 

;A3S0LUTE) 

E0746H 

E0746H 

00?0H 

w 

MEMORY 

MEMORY 
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